While WordPress.com doesn’t allow you to use potentially harmful code on your blog, it does allow you to post source code for general viewing. Provided that you enclose the source code within a [sourcecode] [/sourcecode] shortcode wrapper, you will be able to preserve the code’s formatting; enable syntax highlighting for the programming language used; and highlight specific lines in the code. For example, for a CSS snippet, do:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

[sourcecode language="css" highlight="3,4,5,6,7"]

/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section {
	display: block;
}
body {
	line-height: 1;
}
ol, ul {
	list-style: none;
}
blockquote, q {
	quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
	content: '';
	content: none;
}
table {
	border-collapse: collapse;
	border-spacing: 0;
}

[/sourcecode]

Alternatively, wordpress.com permits embedding github.com gists by using the [gist] shortcode. With [gist]2927943[/gist], you’ll achieve:

… which certainly isn’t as pretty as wordpress.com‘s solution. You can make a gist more presentable by way of CSS customizations, but this isn’t possible on wordpress.com. It is also impossible to tell gists to highlight specific lines of code.

As the future of ootput.bur.st remains bleak, I have been forced to seek alternative hosting locations. wordpress.com provides free hosting for blogs powered by WordPress, and I have chosen to use it as a temporary host while I wait for the outcome of bur.st‘s acquisition.

wordpress.com provides a decent service to the occasional blogger who has no intention of hosting their own site. I personally felt very much at home after successfully importing posts from the Habari-based ootput.bur.st. Of course, as wordpress.com wasn’t a self-hosted solution to the bur.st issue, I was limited to whatever functionality the blog was permitted to exhibit by the WordPress team. (read: no additional plugins allowed)

The transition from Habari to WordPress was not a straightforward process, however. In order to export all of Habari’s posts to a format recognised by wordpress.com, I had to host a WordPress blog on bur.st where I could create the appropriate MySQL tables for WordPress. wordpress.com does not provide direct MySQL access for its members, and this effectively prevents the Habari->Wordpress script from working.

Regardless, once I had exported data to the bur.st-hosted WordPress, I was then able to produce a WordPress->WordPress export file to be imported into wordpress.com

It was a tedious process, but it saved me a lot of time in transferring content onto the new blog.

In order to redirect users to my new wordpress.com blog, and to properly block search bots from accessing the domain (e.g. Google), I created the following two files in ootput.bur.st‘s root directory:
.htaccess:

1
2
3
4

Options +FollowSymLinks
RewriteEngine on
RewriteRule (.*) http://ootput.github.io/$1 [R=301,L]

robots.txt:

1
2
3

User-agent: *
Disallow: /

Of course, these two files will be obliterated once the bur.st merger is officially complete.

NB: Interestingly, my final login to shell.bur.st showed new mail in my mailbox - where I had never received e-mail in the past. There was a total of 10 e-mails, and all of them were spam. I suppose it was someone’s last ditched effort to generate some income from bur.st members - which was kind of lame. As the account effectively expires on the 1st July, this desperate attempt seemed rather stupid.

BUR.ST UPDATE

As you may recall from previous news emails, Bur.st Networking Inc. no longer receives sufficient donations to offer its services. Members of the committee have spent over $3000 of their own money since August 2011 to keep the service running, which is not sustainable. As a direct result of this, the West Australian Internet Association (WAIA) kindly offered to take over providing Bur.st’s services, and is already hosting our servers at no cost while we work to make this happen. WAIA was founded in 1995, operates the West Australian Internet Exchange and has full-time technical staff. Some existing Bur.st volunteers are also going to stick around and give WAIA a hand keeping things running.
After a transition period which will end on 30th June, WAIA will be requiring users to become members of WAIA in order to continue to use the Bur.st services. WAIA is committed to educating the public on the Internet and offers many services to the Internet community. Your membership means WAIA initiatives such as free member public meetings, conferences, arbitration, and increased member services can continue (such as the new offering of Bur.st-like services to members, but it needs your support if the services are to be viable!)

Individual people may obtain WAIA Professional membership, which costs $50 per year. For further details on how to sign up to WAIA please visit
https://www.waia.asn.au/membership

A big advantage of WAIA’s taking over is continuity - you won’t need to set up your website or email address anywhere else, @bur.st email addresses will continue to work, etc. If there is sufficient demand for Bur.st / WAIA hosting in the future, WAIA expects to overhaul the service a bit, particularly to make it easier to manage. However, we expect the functionality that most Bur.st users are using to remain intact. (One significant exception: we do not expect WAIA to continue to provide shell access.)

NOTICE OF SPECIAL GENERAL MEETING

A Special General Meeting of Bur.st Networking Inc. will be held on 5:30pm Wednesday 6 June 2012 at 43 Below Restaurant Lounge Bar, 43 Barrack St (cnr Hay St), Perth, WA

The following special resolution will be proposed: That Bur.st Networking Inc be voluntarily wound up as an incorporated association (under the Associations Incorporation Act 1987).

Voting is open to members of the voting membership class of Bur.st Networking Inc. Voting members who are unable to attend may nominate the secretary to cast a proxy vote on their behalf.

Emails have been sent to all registered voting members - if you believe you should have received one, and have not, please contact secretary@bur.st as soon as possible.

FINAL SIGN OFF

Further updates will be communicated from WAIA in the future. As always, we thank you for your support, albeit small or large, over the many years of Bur.st’s existence. And to all those people who have assisted in some way (you know who you are!) – our hats off to you for your dedication to a great not-for-profit organisation.

Bur.st Executive Committee & Staff
Stay tuned for more developments.

Outlook 2010 adds an unwanted “Junk E-Mail” entry to my Gmail’s list of labels. This can’t be avoided as the automatic folder-list-sync generates the label whenever you launch Outlook. As Gmail adequately deals with my spam emails, I’ve decided to disable Outlook’s anti-spam filters.

To disable the filter, you must create the following registry key and set the DisableAntiSpam value to 1. This will grey out the folder name and prevent access to its settings. Create the path to the key if it does not yet exist.

For Outlook 2010, the key is:

1
2
3

HKEY_CURRENT_USER/Software/Policies/Microsoft/office/14.0/outlook
DWord: DisableAntiSpam
Value: 1 (Hex)

You will first need to identify the device number of the mouse you’d like to configure:

$ xinput list

Logitech USB Gaming Mouse   id=10	[slave  pointer  (2)]

• which is shown in this example as 10. To list the properties of the mouse:

$ xinput list-props 10

Device 'Logitech USB Gaming Mouse':
    ...
    Device Accel Profile (252):     0

The value given determines how the driver handles the acceleration:

-1: none no velocity-dependent pointer acceleration or deceleration. If constant deceleration is also unused, motion processing is suppressed, saving some cycles.

0: classic (the default) similar to old behaviour, but more predictable Xorg Wiki - Development/Documentation/PointerAcceleration

Setting this property to -1 it will disable mouse acceleration entirely.

$ xinput set-prop 10 252 -1

After confirming that the above command works, you can create a shell script to be executed at boot. You may choose to replace the index numbers, eg. 10 and 252 with the more meaningful property names "Logitech USB Gaming Mouse" and "Device Accel Profile" respectively.

My $HOME/bin/macceloff.sh script contains:

1
2
3
4
5
6

#!/bin/bash

sleep 05
xinput set-prop "Logitech USB Gaming Mouse" "Device Accel Profile" -1
exit 0

Tired of sifting through /usr/ports/UPDATING for notes that affect only those packages installed on your system?

Tired of grepping for issues that may have arisen from/to certain dates?

pkg_updating(1) analyses /usr/ports/UPDATING and does the heavy lifting for you.

To obtain the relevant entries from, say, two weeks ago, do:

# /usr/sbin/pkg_updating -d $(/bin/date -v-2w +%Y%m%d)

To rebuild a specific FreeBSD port and the ports that it depends on, for example, with pydf, do:

# portmaster -fR sysutils/pydf

To rebuild all install FreeBSD ports, it’s important to firstly read /usr/ports/UPDATING for any update advisories.

Then, to list ports with issued warnings, do:

# portaudit -a

Once you are confident that the advisories for installed packages are negligible, issue:

# DISABLE_VULNERABILITIES=yes portmaster -R -a -f -B -C -d -G

From portmaster(8):

-R skips ports updated on the previous run
-a checks all ports and updates when needed
-f forces build
-B prevents portmaster from creating a backup package
-G retains custom build config options
-C prevents # make clean from being executed before the build
-d always clean distfiles

DISABLE_VULNERABILITIES=yes prevents portmaster from aborting when an ‘unsafe’ port is encountered.

While testing various memory disk filesystems in FreeBSD, I intelligently made changes to /etc/fstab that pointed to non-existent mountpoints (zroot/usr/home did not exist until later in the boot process - and the system refused to boot into FreeBSD due to mounting errors.)

To remedy this, I booted into my Ubuntu Oneiric installation, which fortunately supported native ZFS (follow this guide). Using the following commands, I was able to mount my root partition zpool - zroot - to make the necessary adjustments to /etc/fstab.

In Ubuntu, as root, list the available zpool imports with:
# zpool import

This will reveal all existing zpools found on all disk drives. Check to see if the zpool can be properly imported by reading the state, status, and action descriptions of the zpool.

Continuing on, create a temporary mountpoint for the zpool:
# mkdir -p /mnt/zpool_temp

Then import the zpool:
# zpool import -N -R /mnt/zpool_temp zroot

To confirm this worked, do:
# zfs list

Also, note the dataset’s original mountpoint value with:
# zfs get mountpoint zroot

Then:
# zfs set mountpoint=/mnt/zpool_temp zroot
# zfs mount zroot

This will temporarily mount the root zpool R/W at /mnt/zpool_temp, allowing you to make the necessary changes.

After you are done making changes to the mounted dataset, while making sure that it is no longer in use:
# zfs unmount zroot

Then, reset the mountpoint to it’s original value:
# zfs set mountpoint=/ zroot

Now reboot the machine without exporting the zpool - this is very important.

Your FreeBSD should now boot properly.

It is possible to use FreeBSD’s MFS Memory Disk to speed up access times of cached web objects.

From md(4):

The md driver provides support for four kinds of memory backed virtual disks:
…
swap:
Backing store is allocated from buffer memory. Pages get pushed out to the swap when the system is under memory pressure, otherwise they stay in the operating memory. Using swap backing is generally preferable over malloc backing.

Chromium’s cache is at $HOME/.cache/chromium, and so, my /etc/fstab contains:

1
2
3
4

# 256M mfs for google chrome
/dev/md0 /home/ootput/.cache/chromium mfs rw,-s256m,-wootput:ootput,noauto 2 0

From mount_mfs(8):

-s256m specifies a memory reservation of 256 M;

-wootput:ootput hands ownership of the mountpoint from root to the user; and

noauto prevents the system from failing to boot properly if the mountpoint does not (yet) exist.

The following additions to /etc/rc.conf were also made:

1
2
3
4
5

mdconfig_md0="-t swap -s 256m"
mdconfig_md0_owner="ootput:ootput"
mdconfig_md0_perms="1777"

which lists arguments to mdconfig(8) for device md0.

At mininum the -t type must be specified and either a -s size for malloc or swap backed md(4) devices or a -f file for vnode backed md(4) devices.

The redundancies found in fstab and rc.conf allows automatic mounting at boot, or manual mounting after boot.

To test the changes made, as root:

# /etc/rc.d/mdconfig restart

On to the $USER/bin/pack_chrome executable script that will both mount the md device, and/or sync contents from the cache at RAM to a backup cache on the HDD:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#!/usr/local/bin/bash

CACHE="$HOME/.cache/chromium"
BACKUP="$CACHE.bak"

for DIR in $CACHE $BACKUP; do
   if [ ! -d "${DIR}" ]; then
      mkdir -p ${DIR}
   fi
done

if test -z "$(/sbin/mount | grep -F "$CACHE" )"; then
    sudo /sbin/mount "$CACHE"
fi

if test -f "$CACHE/.synced"; then
    rsync --exclude '.synced' --exclude '.snap' --delete -avrPx
        "$CACHE/" "$BACKUP"
else
    rsync --delete -avrPx "$BACKUP/" "$CACHE"
    touch "$CACHE/.synced"
fi

The script requires that the $USER is in sudoers(5), and is able to use the /sbin/mount command.

Finally, after $ crontab -e:

1
2
3

*/30 * * * * $HOME/bin/pack_chrome >/dev/null 2>&1

.. and the script gets called every half-hour by cron to automate the syncing process. This also requires that $USER is specifically allowed in /var/cron/allow.

As a reminder to myself:

# pkg_add -r fastest_cvsup
# fastest_cvsup -c all

In /root/stable-supfile, have:

1
2
3
4
5
6
7
8

*default host=cvsup.au.freebsd.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_8
*default delete use-rel-suffix
*default compress
src-all

# csup /root/stable-supfile

# cd /usr/src
# rm -r -f /usr/obj

Customize /etc/make.conf (read notes). Mine contains:

1
2
3
4
5
6
7
8
9
10
11

CPUTYPE?= core2

NO_LPR= YES
NO_NIS= YES
CUPS_OVERWRITE_BASE= YES
NO_INET6= YES

WITH_NVIDIA_GL= YES
WITH_NVIDIA= YES
WITHOUT_NOUVEAU= YES

# script /var/tmp/buildworld-$(date "+%Y%m%d%H%M.%S")

# make -jX buildworld
( where X == number of CPUs + 1 )

# exit
# script /var/tmp/buildkernel-$(date "+%Y%m%d%H%M.%S")

# make buildkernel KODIR=/boot/testing KERNCONF=CUSTOM64
( where CUSTOM64 is documented here )

# make installkernel KODIR=/boot/testing KERNCONF=CUSTOM64
# exit
# nextboot -k testing
# shutdown -r now

# cd /boot
# rm -r -f OLD
# mv kernel OLD
# mv testing kernel

# adjkerntz -i
# rm -rf /etc.old && cp -Rp /etc /etc.old
# mergemaster -p
# cd /usr/src
# make installworld
# mergemaster -iU
# make delete-old
# shutdown -r now

NB: NO_NIS in /etc/make.conf requires the following changes in /etc/nsswitch.conf:

1
2
3

group: files
passwd: files

If you’re feeling game, you can try the following commands to save yourself some keystrokes and delays:

# csup /root/stable-supfile && rm -r -f /usr/obj && cd /usr/src && make -j5 buildworld && make buildkernel KODIR=/boot/testing KERNCONF=CUSTOM64 && make installkernel KODIR=/boot/testing KERNCONF=CUSTOM64 && cd /boot && rm -r -f OLD && mv kernel OLD && mv testing kernel && reboot

Here, you can revert back to the old kernel if you experience boot up problems. Otherwise, continue with:

# adjkerntz -i && rm -rf /etc.old && cp -Rp /etc /etc.old && mergemaster -p && cd /usr/src && make installworld && mergemaster -iU && make delete-old && reboot