.plan - now over HTTP, for people who don't know how to use finger(1)

@400000004c449e2d0c0435c4
Project: Mature UNIX Japanese support at last?
Plan:

The SCIM input method has been one of the most flexible and practical
input engines for inputting asian languages on UNIX for quite a while
now. Unfortunately, it's also always been incredibly unstable, buggy and
poorly maintained, and is now effectively dead despite its inclusion
in many UNIX desktop distributions. I've been trying to maintain the
FreeBSD SCIM infrastructure for a while now, with limited success.

Thankfully, Google has stepped in to create IBus
https://code.google.com/p/ibus/, a new and modern input method which
supports several conversion engines -- notably Anthy, which should make
transition for most Japanese SCIM users easy; but also mozc, Google's
new multiplatform Japanese input method, which has some cute security
features and will probably supplant Anthy.

I've updated my tutorial to use IBus and Anthy/mozc, and removed some of
the irrelevant cruft. I'll probably drop my maintainership of SCIM soon,
and good riddance.

http://grumplicio.us/fbsd_japanese.html



Comment Link


@400000004c341b2a1415bb34 Project: This can't be right Plan: I upgraded my work laptop from an X61 to a T410s. Shockingly, everything works -- wireless, video (once I locked the BIOS to use only the nvidia chip instead of the fake ``Intel'' one), sound (once I told it not to play sound through the HDMI output), etc. I even got everything booting from a GELI device inside a ZFS pool, bootstrapped by a USB key. We'll see how the battery life goes, but I'm pleasantly surprised to have FreeBSD work out of the box on such a new system.
Comment Link


@400000004c094e0233cd48ac Project: Jabber returns Plan: I've finally got a Jabber server back up on redundancy, after ages of it being down due to the fact that there's no Java implementation for FreeBSD on PowerPC. I wasn't going to run some server written in Erlang or somesuch nonsense -- I tried once, and it was not a pretty experience -- and I most certainly won't run such an implementation of such a complex network service written in C. Thankfully, I discovered Prosody http://prosody.im, which is a tiny and simple XMPP server written in Lua. Had to fix a small thing to make Lua work in the first place on PPC (-fPIC), but after that, it was pretty smooth sailing. For people that just run a small server and want their own XMPP service without the bloatiness of Java and Openfire, I recommend it.
Comment Link


@400000004bca0e7d377f2164 Project: Week 1 of Android Plan: I switched to a Nexus One last week due to a hardware failure on my iPhone. I won't get another iPhone, in spite of it being the best mobile platform available, due to Apple's intense evil in the handling of said platform. Here are my impressions. Well, complaints, really. 1) SMS notifications don't appear on the lock screen. This means I have to unlock and pull down the notifications panel just to see who texted me. All mention of this online is from people wanting to *disable* this feature, which is apparently present on the Hero. 2) Exchange integration is pathetic. I know that the Droid has good integration, but I'm using T-Mobile, as they're the one telco who didn't participate in warrantless wiretaps. As has been noted, the N1 only syncs e-mail and contacts with Exchange, and does so reasonably well. For calendaring, you have to buy Touchdown, which doesn't integrate terribly well. It also means that you have to have Touchdown sync your e-mail as well, so that you get invites (which, by the way, you aren't alerted to receiving), which causes extra battery drain. I'm basically going to have to roll my own ROM with Motorola's calendaring APK. The lack of enterprise support in the base OS is just lazy - in the iPhone, Exchange integration is phenomenal. Android seems to be designed for the unemployed. 3) The XMPP client only talks to Google Talk. Not terribly surprising, but stupid. I don't use Google Talk, Gmail, Gcalendar, or anything G other than search (and Android). 4) Similarly, the calendar app *only* supports Google Calendar. You can't subscribe to remote ICS files, which is how I generally aggregate my various schedules. You can't even have a local calendar; you have to actually go subscribe to these in Google Calendar on a computer, and then supposedly they'll sync to your phone. I'll never know this, though, because I'm not going to tell Google what I'm doing at every given moment. And obviously, this calendar doesn't talk to the Exchange one. So, scheduling and calendaring on this device is basically impossible. 5) There isn't an application for TAKING NOTES. Come ON, people, this is practically a hello world app. EVERY PHONE HAS ONE. My StarTac 10 years ago probably had one. It's a total cop-out to rely on "the community" to make your basic apps for you. On the hardware end, there are some niggles, like the touchscreen seems to be miscalibrated to recognize taps slightly above where they should be, the fact that the trackball isn't sensitive enough and is otherwise basically useless, and the fairly bad GPS signal aquisition. Basically, this is an unpolished Symbian phone, but with a semi-open-source model, non-fascist app store and slightly nicer development platform (albeit one that still sucks horribly compared to Objective-C + Cocoa Touch + Xcode). Not impressed, but I'll stick with it, as it seems the only non-Apple game in town.
Comment Link


@400000004bc7a84d353f2ffc Project: OpenSSH configuration: Threat or Menace? Plan: So, the ASF got compromised: https://blogs.apache.org/infra/entry/apache_org_04_09_2010 The writeup mentions SSHD configuration: """SSH passwords should not have been enabled for login over the Internet. Although the Infrastructure Team had attempted to configure the sshd daemon to disable password-based logins, having UsePAM yes set meant that password-based logins were still possible.""" What? Let's take a closer look at the man page for sshd_config: # Set this to 'no' to disable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #UsePAM yes Ok, that's rather ridiculous -- PermitRootLogin without-password shouldn't pass things to PAM, in my opinion. Yes, I know PAM isn't always password auth, but it almost always is. Now, is UsePAM on or off by default? Looking below, I see: #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding yes Since I know these are off by default in OpenSSH, I assume ``UsePAM yes'' means UsePAM is off. This is wrong -- the man page explains at the top that the commented values are the defaults. However, here's a the snip from FreeBSD's sshd_config man page: X11Forwarding Specifies whether X11 forwarding is permitted. The argument must be ``yes'' or ``no''. The default is ``yes''. And here is Ubuntu's: X11Forwarding Specifies whether X11 forwarding is permitted. The argument must be ``yes'' or ``no''. The default is ``no''. I see. Also in the man page on Ubuntu is this: Note that the Debian openssh-server package sets several options as standard in /etc/ssh/sshd_config which are not the default in sshd(8). The exact list depends on whether the package was installed fresh or upgraded from various possible previous versions, but includes at least the following: * Protocol 2 * ChallengeResponseAuthentication no * X11Forwarding yes * PrintMotd no * AcceptEnv LANG LC_* * Subsystem sftp /usr/lib/openssh/sftp-server * UsePAM yes Well, it's no wonder people are confused. You have FreeBSD transparently changing the long-standing default options (albeit correctly, if you were going to do such a thing), and Debian saying ``The default options in this man page are for the OpenBSD version of OpenSSH. We may have changed some of them, but you can't be sure which ones. Have a nice day.''
Comment Link


@400000004bba674b2e812c9c Project: Waving goodbye to sysinstall Plan: I just did a vanilla FreeBSD install onto a ZFS root partition using PC-BSD's installer, instead of spending probably an entire day trying to figure out how to use ZFS root as I did last time. Good job, guys, this is a big win. http://pcbsd.org
Comment Link


@400000004b96dde70c1e60fc Project: Saving my eyes Plan: I'm not sure why I waited so long to switch to Inconsolata after I was first exposed to it, but after several weeks of stinging eyes, I finally switched. This also involved switching to a Tango-based terminal theme, using vim in 256 color mode, and bumping font size up, and my eyes felt better after mere minutes. I saw mention somewhere that small fonts can cause high blood pressure and stress, which is a cute idea, but haven't found any studies. Anyway: http://www.levien.com/type/myfonts/inconsolata.html
Comment Link


@400000004b75d20c0392063c Project: SSL and open source fools Plan: As much as I'm involved with and enjoy using open source software, the open source ``community'' is largely incompetent when it comes to security. Take for example the thread at: http://article.gmane.org/gmane.comp.misc.suckless/920 There is a long-standing and disastrously false belief that there is some benefit to encrypting communications without bothering to check who you're encrypting them to. THERE ISN'T. None whatsoever. Middle-person attacks happen ALL the TIME, and the tools to do it are just as easy, if not easier, than using tcpdump. Even security people get bitten by this, including one prominent one who had his entire mail spool stolen because he used fetchmail to retrieve it: fetchmail silently failed to validate certificates. However, I keep running into this idea, especially with open source cranks. The FreeBSD security team refused to consider it an issue that libfetch, which is used to retrieve files by pkg_add(1) by default, silently establishes SSL connections without performing any verification. A patch to fix the problem was ignored, and I was requested to go fuck myself for impugning the quality of the code in the first place. It seems these developers want to beat on their chests about how untrustworthy public CAs are (they are), but do nothing to actually help solve the problem except to pretend that SSL will magically work on its own, thus exposing users to even greater risk than just refusing to do SSL at all. A CA does not have to be a public CA: it can be a corporate or personal CA. You don't have to even use CA verification -- you can use SSH-style fingerprint verification. You can use both. Or any number of other things. But righteously ignoring the problem is asinine behavior.
Comment Link


@400000004b478e1a2d9fd134 Project: more of a browser "police action" Plan: Ok, I've gotten progressively more frustrated with Firefox, even with the wonderful vimperator. Its performance is just staggeringly bad, especially on non-Windows platforms. Originally I had looked at uzbl http://uzbl.org, but the decision to use external shell and python scripts to handle cookies and such was just too cracked out. Besides performance concerns, it's likely a security nightmare, and way too much fiddling to spend on a browser. Surf http://surf.suckless.org/ is a very nice minimal browser -- extremely fast, small, and customizable via a dwm-style config.h. I like surf a lot, but was missing the link hinting from vimperator, so happily I found vimprobable http://www.yllr.net/vimprobable/. I use vimprobable1. This behaves largely quite like firefox + vimperator, except it's stupidly fast, configured through config.h and doesn't use tabs. Since I use a tiling window manager, I don't really care about having tabs. For those that do, you can use tabbed http://tools.suckless.org/tabbed, which is a far more sensible way to deal with tabbing applications. This works with uzbl, surf, vimprobable, or anything else that supports the XEmbed protocol. All 3 browsers are based on webkit-gtk2, so they render more or less how Safari/Chrome/whatever do. For those that are a little less vimish and/or minimal, there's also Arora, which is light, cross-platform, fairly featureful and based on webkit-qt4. http://code.google.com/p/arora/ It has builtin adblocking, password management, private browsing mode, and tabs. A nice drop-in for your everyday Firefox user.
Comment Link


@400000004b2a842b0c2b97cc Project: vi everywhere Plan: I'm a big fan of vimperator et al (http://www.vimperator.org/), and with the release of Thunderbird 3 and muttator, I may finally get pulled away from mutt. Of course, I've said that before. Tbird3 has some pretty nice features --- it's a good RSS reader, the search is well-designed and basically instantaneous, and its Archive feature helps organize old stuff pretty well. And it beats the pants off of webmail, as if that were hard to do.
Comment Link


@400000004a5e1b3e37cfc204 Project: dwm update Plan: dwm 5.6 has just been released, with multihead support. Yay! It now does everything I want. My local repo is at http://redundancy.redundancy.org/dwm.tar.gz. Aside from a smattering of config changes and third party patches, the main addition is a simple ``focusurgent'' patch, which warps you to the next window with the EXWMH ``URGENT'' hint set. I use this with pidgin, which can set the hint on new messages, and also with urxvt, which can set the urgent hint on terminal bell. Since dwm highlights tags with urgent hints set, this acts as both new IM notification and new mail notification (as mutt uses a terminal bell when new mail arrives). If people want to use this in their own dwm configs: void focusurgent(Arg *x) Client *c; for(c = selmon->stack; c && !(c->isurgent); c = c->snext); if(c) Arg a; a.ui=c->tags; view(&a); focus(c);
Comment Link


@400000004a39324e1e481d04 Project: Code review tips for vim Plan: I have to spend a fair amount of my time doing source code review. I've tried using tools like the hideous Source Insight, but for all its flaws, I always come back to vim. There are a few things that I've been adding lately though that have made it a bit more efficient. Here's what I use: exuberant ctags -- ctags are simple to use: exctags -R . This creates a file called tags in the CWD. I have in my .vimrc simply ``set tags=tags'', so the one in the CWD is always used. At the top of a source tree, I make the tagfile, start vim, and then use ``:Explore'' to browse to the source files I want. ctags usage in vim is just ^] to jump to a symbol definition, and ^T to go back. cscope -- short story: cscope -R ^D Once in vim again, you can go to a symbol and do ^\-s to see a lookup of where that symbol is used in the codebase, or ^\-c to see callers. Pick a number and you jump to it. Similar to ctags, ^T jumps back. You'll want to put http://cscope.sourceforge.net/cscope_maps.vim into your vim plugin directory for all of this to work. Taglist -- The vim taglist plugin will show you a sidebar with all of the symbols in a file and/or source tree, giving you a good overview and letting you jump around. It's pretty simple to use, just remember ^W^W switches between different vim panels. After you've installed it, (just put it in your .vim/plugin dir), use ``:TlistToggle'' to activate it. Same deal: after a jump, use ^T to go back on the stack. NerdTree -- A nice and simple directory browser sidebar, with some extra nifty features. Quite nice and actively maintained. Much better than :Ex. flawfinder -- a hokey script, but it does most of the grepping for nasty standard library functions that no one should be using. The neat thing here is that you can use the output as a tool in vim. To do this, first move your cscope.out and tags file somewhere else for a bit -- they confuse flawfinder. Then, at the root of the source tree, do: flawfinder -SQD --followdotdir . > flawfile Now, start up vim and do ``:copen'' to open up a ``QuickFix'' panel. Then do ``:cf flawfile'' to read in the flawfinder results. You now have a browsable list of issues that you can run through. ``:cn'' goes to the next hit. Now that you see what a hitlist looks like, you can use this for other stuff too -- the format is trivial. Of course there are a huge number of handy vim tricks. It's actually worth reading the :help, as it's surprisingly usable and enlightening. You might also want to check http://vim.wikia.com/wiki/Best_Vim_Tips for some other handy tips.
Comment Link


@400000004a02199c04d0a88c Project: Undisclosed Plan: My nice discoveries for the day are the ``magic ='' and ``magic **'' in zsh, and fefe's ``gatling'' webserver. I wouldn't replace publicfile with it, but for quick and dirty exporting of the CWD, it'll come in very handy. http://www.fefe.de/gatling/ http://www.rayninfo.co.uk/tips/zshtips.html
Comment Link


@4000000049f62fff2ecaef6c Project: Revolutionizing content management. Plan: I did some work this weekend on my ultra-cranky ``blogging'' software, and it's working quite nicely. I'm kicking around the idea of exporting to LaTeX, but I'm not quite sure how well that'll really work. I wish LaTeX to HTML translators didn't all suck. I'll definitely add support for RSS, though. Source for this is at http://redundancy.redundancy.org/plan.sh.
Comment Link


@4000000049f3fea32482d31c Project: Being bleary. Plan: I've been doing some hacking on dwm (http://dwm.suckless.org) as of late, and have been quite enjoying it. I have a little repo of the way I set it up, and it's quite delightful. You can find it at http://redundancy.redundancy.org/dwm.tar.gz.
Comment Link


@4000000049ebc0b6278b582c Project: I'm supposed to be writing. Plan: http://en.wikipedia.org/wiki/Dennis_Rader ``The police corresponded with the BTK Killer (Rader) in an effort to gain his confidence. Then, in one of his communications with police, Rader asked them if it were possible to trace information from floppy disks. The police department replied that there was no way of knowing what computer such a disk had been used on, when in fact such ways existed. Rader then sent his message and floppy to the police department, which quickly checked the metadata of the Microsoft Word document. In the metadata, they found that the document had been made by a man who called himself Dennis. They also found a link to the Lutheran Church. When the police searched on the Internet for `Lutheran Church Wichita Dennis', they found his family name, and were able to identify a suspect: Dennis Rader, a Lutheran Deacon.''
Comment Link