With Chyrp development dead in the water, I had to find a worthwhile alternative. Wordpress, while no doubt a popular and proven platform, seemed a bit too complex for my needs. Still, as my experience with blogging platforms was virtually nil, I had no choice but to make it a major consideration.

Upon searching for Wordpress themes, I chanced upon some Habari themes, oddly enough. After browsing Habari’s wiki pages, I soon realized that it was not so different from Chyrp - besides a much more active Habari community. A trial run of Habari on this host showed that it was probably the closest thing to Chyrp that I could ever find, and it has remained on this host since.

Habari is different

While there are a number of technical reasons that highlight the differences and advantages Habari has over other blogging packages, a major component of what makes Habari different is its community participation model. Users who demonstrate a level of quality contributions to the project are granted more privileges within the project. Habari’s intro page

I was saddened to recently hear that work on Chryp had officially ended. It’s really a shame, as Chyrp provided everything I needed at a fraction of the resources required by functionally-similar blog engines. It was the most aesthetically pleasing blogging engine I had come across, and it offered unparalleled simplicity.

As much as I would love to stay with Chyrp’s frozen state of code, I can’t dismiss the number of outstanding bugs on the platform. Also, as the code is relatively new, and the community relatively quiet in terms of feedback (moreso now after current events), it won’t be a security-conscious move for me to stay on board. l’ll have to find a blog engine with a similarly low footprint and a more active community.

Salvaged from the author’s site were these final words:

As you may have noticed, progress on Chyrp has grinded to a halt, and has been in that state for a long while now. It is no longer maintained. A few people have volunteered to step in, which I appreciate, but no progress has been made. Throughout this project’s timeline I can count the repeated contributors on one hand (whom I am eternally grateful for; Twig, a lot of internal refactoring, and many fixes are the result of their hard work). It’s unhealthy for a project to rely too much on one maintainer; when they lose interest the whole thing crumbles down. This is essentially what’s happened. People keep switching to, finding, or using Chyrp, which just isn’t a good idea for me to encourage given Chyrp’s current state. So now I’m announcing it’s death.

Chyrp will always be available at GitHub. Any contributors can feel free to fork my repository; I’d be more than happy to accept patches and security fixes, or add you as a committer if you seem trustworthy and active enough. But I will no longer be working on this project, I probably won’t be in the IRC channel anymore, and I can no longer guarantee that this site will stick around through server moves and such. Unless a miracle happens and Chyrp development springs from the grave (which will be judged by actions, not words).

Chyrp has been a part of my life since I first learned to program. It grew out of what is now a “hello world”: writing a blog engine. It has spanned a decent chunk of my critically-thinking life. Thanks for being a part of this project, whether you were a user or a contributor. Chyrp author’s blog

Read this bug report.

What’s wrong with that picture?

We’re dealing with a bug that prevents display of $HOME contents via Nautilus browsing and simple shell commands such as $ ls -al . Awesome, huh?

For a Linux distribution that promotes the use of the Gnome desktop environment, it sure does seem that Fedora, and it’s #fedora@freenode legion of bigoted IRC veterans, are dismissive of the bug; a casual mention for the wary does not count.

What this means is that whenever the bug rears it’s ugly head i.e. always, the user’s desktop experience is ruined - personal configurations for applications can’t be accessed.

Since 2009-04-02 05:39:58 EDT, this bug has remained officially unresolved.

A temporary solution for the casual home user that does not involve patching files is to # touch /forcefsck as root, for the next system boot to (hopefully) fix the problem for the duration of the computer’s uptime. Even then, successive reboots (expect to reboot often) requires the user to repeatedly issue the same command.

My non-geek of a girlfriend was not particularly pleased.

The plymouth-toolset does not come with documented command-line options, and I had to infer the following commands from the bash scripts provided with the package:

# plymouth-set-default-theme --list

# plymouth-set-default-theme --rebuild-initrd

In order to get the G5’s side buttons and 3rd button’s left/right tilt functional in both Firefox and Nautilus, in /etc/X11/xorg.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Section "ServerLayout"
   #...
   InputDevice "Configured Mouse" "Pointer"
EndSection

Section "InputDevice"
   Identifier "Configured Mouse"
   Driver "evdev"
   Option "CorePointer"
   Option "Name" "Logitech USB Gaming Mouse"
   Option "ZAxisMapping" "4 5 6 7"
   Option "Emulate3Buttons" "false"
EndSection

NB: F12 does not ship with a /etc/X11/xorg.conf file by default; see Fedora’s guide on how to create one.

Additionally, you need to modify $HOME/.Xmodmap to show:

1
2

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

Also, after:

# yum install xbindkeys xdotool

.. in $HOME/.xbindkeysrc, have:

1
2
3
4
5
6
7
8

# Nautilus:Back
"xdotool key alt+Left"
  b:8

# Nautilus:Forward
"xdotool key alt+Right"
  b:9

To upload gists from the command-line, follow [these instructions](http://github.com/defunkt/gist/blob/master/README.markdown). The given usage example shows:

$ gist < file.txt
$ echo secret | gist --private # or -p
$ echo "puts :hi" | gist -t rb
$ gist script.py
$ gist script.js notes.txt
$ pbpaste | gist -p # Copy from clipboard - OSX Only
$ gist -
the quick brown fox jumps over the lazy dog
^D

Github allows users to interact with their online profile (account details, repo details etc) via several APIs separate from the standard web-interface. This proves useful, if, say, you need to remove a problematic repo entirely from Github, and the web interface won’t let you access the repo page, citing error: page not found.

From the instructions given:

$ curl -F 'login=ootput' -F 'token=_API_TOKEN_HERE_' https://github.com/api/v2/json/repos/delete/_REPO_NAME_

(The API_TOKEN_HERE can be found in Account Settings, under Administrative Information.)

If the curl command succeeds, it will return something similar to {"delete_token":"abcdefgh"}. Use this token in the following:

$ curl -F 'login=ootput' -F 'token=_API_TOKEN_HERE_' -F 'delete_token=abcdefgh' https://github.com/api/v2/json/repos/delete/_REPO_NAME_

If all goes well, curl will return {"status":"deleted"}

You can use the -k (or --insecure) option for curl to bypass certificate verification.

Syntax highlighting of published code makes for much prettier more legible code.

I experimented with several of the more common pastebin-like services: with Github’s gist service, and with the original Pastebin.com service.

Here’s an example from pastebin:


Compare that to Github’s gists:


Gists also have line numbers, but they’re only visible when viewed directly, e.g. here

With recent developments, I no longer have a need for NB. While it was a nice run, my faith in the longevity of the software waned when I read:

February 12, 2010 8:52 PM

Fight Bit Rot - Join The NanoBlogger Development Team Today!

In all seriousness, I’m looking for two or more people to take on developer roles. Specifically people who have skills in programming and debugging shell scripts. Even if writing code isn’t your cup of joe, just helping patch and push new releases out would be a huge boost to the project’s vitality.

I have a backlog of bugs that need fixing and can’t seem to find the time to sit down and start widdling away at them. So, anybody out there interested?

… to which there hasn’t been a single reply.

Farewell, NB, and thanks for all the fish.

Readernaut is the easiest way to share what you’re reading with friends.

Chyrp’s Readernaut module provides a sample twig:

Twig, a language specifically created for Chyrp, that is put through a compiler to produce PHP.

… that is unnecessarily complicated - it essentially tries to fit both the book title and book cover into a table column. I’d much rather allocate space for the book’s cover than it’s details given the small area to work with.

Ultimately, I modified themes/$theme/content/sidebar.twig to show:

To restrict the book listing to only show books that are currently being read, in modules/readernaut/readernaut.php:

1
2
3
4
5
6

## The actual data
public function books($limit=10) {
   $config = Config::current();
   $xml = simplexml_load_string(get_remote('http://readernaut.com/api/v1/xml/'.$config->readernaut_user.'/books/reading/?limit='.$limit));
   return $xml->reader_book;
}

.. essentially changing the path to the reading list from books/ to books/reading/.