I am betting that Luakit will be more usable than Uzbl within a week. I am also betting that I will hear chirping about Luakit not integrating with the Monkeysphere, and though I agree that this is a problem, it seems to be difficult to solve.
To do it correctly, one would need hooks or callbacks in WebKitGTK+, which, in turn, would need support in LibSoup, which would probably then need support in GnuTLS.
Since apparently this will take years of bickering to accomplish, perhaps some sort of hack is called for. I suppose one could, for each HTTPS URL visited, make an OOB connection, download the certificate, and then run it through Monkeysphere validation, before then letting WebKitGTK+ make another connection and download (hopefully the same) certificate a second time.
This strikes me as ugly and problematic. Ideas?
Posted Fri Aug 13 14:54:16 2010Processor : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 799.53
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc08
CPU revision : 5
Hardware : Genesi Efika MX
Revision : 51030
Serial : 0000000000000000`
total used free shared buffers cached
Mem: 482740 44836 437904 0 4672 21104
-/+ buffers/cache: 19060 463680
Swap: 0 0 0
Bus 002 Device 002: ID 0b95:772a ASIX Electronics Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 13d3:3273 IMC Networks 802.11 n/g/b Wireless LAN USB Mini-Card
Bus 001 Device 002: ID 1a40:0101 TERMINUS TECHNOLOGY INC. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
% sudo fw_printenv | sed 's/^/sudo fw_setenv /;s/=/ "/;s/$/"/;'
sudo fw_setenv bootcmd "setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000;"
sudo fw_setenv bootdelay "3"
sudo fw_setenv baudrate "115200"
sudo fw_setenv x_bootcmd_ethernet "ping 192.168.2.1"
sudo fw_setenv x_bootcmd_usb "usb start"
sudo fw_setenv x_bootcmd_kernel "nand read.e 0x6400000 0x100000 0x400000"
sudo fw_setenv x_bootargs "console=ttyS0,115200"
sudo fw_setenv x_bootargs_root "ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs"
sudo fw_setenv stdin "serial"
sudo fw_setenv stdout "serial"
sudo fw_setenv stderr "serial"
sudo fw_setenv ethact "egiga0"
sudo fw_setenv ethaddr "00:99:99:99:99:99"
sudo fw_setenv eth1addr "00:99:99:99:99:98"
I am staring at three different “plug” computers and wondering how many more will appear.
They are in varying states of Debianness: all are running squeeze, but the GuruPlug is the only one that's “pure”. The SheevaPlug is running a wacky version of U-Boot, because the u-boot package in Debian can't cope with the SD card device. Hopefully this can be fixed some year.
Worse yet is the FreeAgent DockStar, which is running a foreign kernel and two (TWO) foreign U-Boots (the first one chains to the second one which then boots off a USB stick). Unfortunately I'm afraid to correct these things because, unlike the other two, it is not a developer board, and messing it up would mean trying to deal with 3.3V RS-232 or something equally unpleasant. As it is, bricking one of the plugs where I actually have serial/JTAG causes enough emotional turmoil.
Posted Sat Jul 3 22:37:15 2010What seems like eons ago, I ordered one of those SheevaPlug Development Kits. After about six weeks, they got around to shipping it, and then, yesterday, after I assume a tortoise had piloted it across the country on broken tricycle, it was finally delivered to me.
I booted it up, observed that there was some kind of Ubuntu thing on it, and set myself to correct that problem. Within an hour I had managed to lock myself out.
Here is something I should have read beforehand.
Thanks to Martin Michlmayr, it is now running Debian and allowing me to log in.
Here are some steps to follow if you would like to boot Debian off of a USB stick plugged into your Sheevaplug:
- Grab the tarball from http://people.debian.org/~tbm/sheevaplug/lenny/
- Make an ext3 filesystem on the first partition of your USB stick (ext2 will not work with the current image)
- Mount the USB stick's filesystem, unpack the tarball onto it, then unmount
- Plug the USB stick into the SheevaPlug's full-sized USB port
- Plug the SheevaPlug in, and use minicom or your favorite terminal program to console in over the mini-USB port (don't forget that you need to use the ftdi_sio module instead of usbserial; 115200,N,8,1, no flow control)
Abort the autoboot, and type the following commands:
setenv mainlineLinux yes setenv arcNumber 2097 saveenv reset setenv bootargs_root 'root=/dev/sda1 rootdelay=10' setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x0800000 /boot/uInitrd; ext2load usb 0:1 0x400000 /boot/uImage' setenv bootcmd 'setenv bootargs $(console) $(bootargs_root); run bootcmd_usb; bootm 0x400000 0x0800000' saveenv run bootcmd
That should be all there is to it.
Next I'm wondering if SDIO wireless cards work.
Posted Wed Apr 29 18:20:19 2009This is about two things that are not robust.
zomg, as of version 0.5.7, can play libre.fm radio streams without modification. It does not do this particularly well.
As of today a second type of libre.fm radio stream is available, so I will give two illustrative examples:
To play free music tagged 'Blues' (note that almost none of this is actually blues),
zomg -r librefm://globaltags/Blues
To play free music performed only by Abscondo (note that the "similarartists" is there to mislead you):
zomg -r librefm://artist/Abscondo/similarartists
These stations lack the intelligence to avoid annoying duplication or much of anything but randomization. However, both zomg and libre.fm are free software, and anyone can chip in and improve this if desired.
In other news, the state of client support has moved a bit, though not as much as one might have hoped. You can get a picture of that here.
Posted Sun Apr 26 21:59:52 2009As far as I am aware (and I am unanimous in this), ZOMG is the only released software that can scrobble tracks to both libre.fm and last.fm near-simultaneously.
Posted Tue Apr 7 11:12:18 2009certtool --generate-privkey > cakey.pem
echo 'cn = exampleCA' > ca.tmpl
echo 'ca' >> ca.tmpl
echo 'cert_signing_key' >> ca.tmpl
echo 'expiration_days = 732' >> ca.tmpl
certtool --generate-self-signed --load-privkey cakey.pem \
--template ca.tmpl --outfile cacert.pem
for i in host1.example.org host2.example.org host3.example.org
do
certtool --generate-privkey > $i-key.pem
echo 'organization = Example' > server.tmpl
echo 'unit = Messaging' >>server.tmpl
echo "cn = $i" >> server.tmpl
echo 'email = postmaster@example.org' >> server.tmpl
echo 'expiration_days = 366' >> server.tmpl
# echo 'tls_www_server' >> server.tmpl
echo 'encryption_key' >> server.tmpl
echo 'signing_key' >> server.tmpl
echo "dns_name = $i" >> server.tmpl
certtool --generate-certificate --load-privkey $i-key.pem \
--load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
--template server.tmpl --outfile $i.pem
done
A long time ago, I had the idea of improving the interface between
shell completion and the programs being completed. The result of
this was the bzr shell-complete command (or bzr s-c for short),
which was never fully fleshed out, and has since fallen into disrepair.
The principles behind this are + the program is the best place to store up-to-date and accurate information + the program already knows all these things (albeit usually in unparseable forms) + duplicating information and effort is annoying
Here is an excerpt from bzr s-c, which was intended to give a comprehensive
list of subcommands, paired with short descriptions:
diff:show differences in the working tree, between revisions or branches
export:export current or past revision to a destination directory or archive
get:create a new copy of a branch
help:show help on a command or other topic
ignore:ignore specified files or patterns
ignored:list ignored files and the patterns that matched them
info:show information about a working tree, branch or repository
init:make a directory into a versioned branch
There is one subcommand per line, separated from its description by a colon.
Next you can invoke something like bzr s-c diff to get the possible options
and arguments for the diff subcommand, although the output you would see today
is broken and nearly useless.
Since I've lost faith in bzr, I'll illustrate what the output might be
corresponding to topgit's tg remote if topgit supported this kind of thing:
--populate
REMOTE
This would mean that tg remote can understand the option --populate, which
takes no argument, and that the first non-option argument should be a
REMOTE.
REMOTE would then be defined, for example, in zsh's _topgit function as
some kind of git remote which is completed in the same way you might complete
a git remote for git.
The exciting part then, is that if tg remote starts taking a --decimate
option, the topgit completion helper subsystem will start outputting it
and _topgit will do the right thing without having to be altered.
For tg export, things are a bit more complicated, so let's have it be
described in the style of the zsh completion system:
'(--collapse)--quilt:directory:_directories'
'(--collapse -b --branch)'{-b,--branch=}':branches:BRANCHES'
'(--quilt)--collapse:branch:BRANCH'
This means that --collapse and --quilt are exclusive, that -b
and --branch cannot be used with --collapse, that -b and
--branch are equivalent, that -b and --branch take an argument
in the form of BRANCHES, that --collapse takes an argument in the
form of BRANCH, and that --quilt takes an argument that's a
real directory in the filesystem.
Then _topgit would have logic to interpret BRANCH as a branch, and
BRANCHES as a comma-separated list of branches.
A similar idea is the one used by axp. If you invoke axp self completion zsh,
it will output zsh completion functions for you. To me this seems more onerous
on both the developers and the end users, but I suppose it gives you immediate
flexibility that a more generic interface would lack.