I managed to play 3 pranks on myself today.
Taught my cat how to leave the house by the cat-flap, but not how to come in by it. (Or maybe he just doesn't want to.) Thus, I am constantly his doorman. This took some setup, the best pranks do.
Got a minor amount of hot pepper in my eye, then forgot about it, washed my face, and got the rest of the oil in my eye, leading to a farcical dance around the kitchen.
Unplugged my dialup gateway to save power overnight (sun has been scarce lately), and had a "how can I be online" moment hours later. Forgot that I've been using a power-hungry laptop there as my nslu2 is ill.
After two weeks of work, I've just released git-annex version 0.20110417, with some big new features that open up some interesting use cases:
Want to use The Cloud as a git remote? git-annex now supports storing data in Amazon S3 as if it were just another git remote. With full gpg encryption of the content stored in S3.
*This is so easy to use and neato I just have to show it off:
joey@gnu:~/tmp/repo> git annex initremote cloud type=S3 encryption=joey@kitenet.net initremote cloud (checking bucket) (creating bucket in US) ok joey@gnu:~/tmp/repo> git annex add bigfile add bigfile ok (Recording state in git...) joey@gnu:~/tmp/repo> git annex move bigfile --to cloud move bigfile (gpg) (checking cloud...) (to cloud...) ok (Recording state in git...) joey@gnu:~/tmp/repo> file bigfile bigfile: broken symbolic link joey@gnu:~/tmp/repo> git annex get bigfile get bigfile (copying from cloud...) (gpg) ok (Recording state in git...) joey@gnu:~/tmp/repo> file bigfile bigfile: symbolic link
Want to collaborate on some big files? Perhaps you're dealing with scientific datasets, or video game levels. git-annex can now use a bup repository as a special kind of git remote. The big files are stored forevermore in bup's git repository, while their metadata and the rest of your stuff can be kept in git as usual -- and both git repositories can be used collaboratively. It's turtlesWgit all the way down, but without the large file scalability problems.
Want to trade disk space with someone? You can set up a bup remote, or just bare directory on their system, and have git-annex encrypt the data it stores there.
Want a DropBox like folder that's Free Software and stores data in the cloud, or in a more git-style distributed way? Well, about that...
I had been planning to finish up S3 and encryption support, and then mention this could perhaps be used as the basis for a DropBox like thing. But Christophe-Marie Duquesne anticipated me by a month, and created ShareBox. It's a FUSE filesystem layered over git-annex. While not yet production ready (lacking eg, conflict resolution), it has promise.
* This feature isn't available in Debian yet, blocked by a lack of
the Haskell hS3 library packaged for Debian. Someone should fix that,
ideally not me. Getting missingh updated for the ghc7 transition
so git-annex is buildable in unstable would also be nice..
I have noticed some problems with how Debian is using the popularity-contest data.
popcon units are unknown
Using the popcon score of a package to measure its use is like using the bleeple score of a trip to measure its distance. Both scores have no sensible units attached, though they may be loosely derived from a unit value. Is a trip with a bleeple score of 99 a long trip? Is a package with a popcon score of 99 a rarely used package?
The only way to resolve this ambiguity at all is to compare ratios of values, so the problimatic units cancel out. A flight from NYC to AMS with a bleepie score of 99 is 50 times as bleepie as my drive home, which scores 2.
So, any statement like "low popcon score" is basically so lacking in context as to be meaningless. Such statements are deprecated, and should be ignored.
not all popcon scores are comparable
The above example is intentionally bad. Plane flights and car trips are not very comparable when you don't know what units (time / CO2 / distance / number of people sharing a confined space / security theater points) are being used.
Similarly, comparing a high popcon package like gnome-terminal with a relatively low popcon package like udhcpc is very deceptive. The former is installed by default in the desktop task, but plenty of desktop users would not miss it. The latter is installed only on embedded systems, which can exist in absurd numbers, and none of which will tend to report to popcon.
So, any attempt to compare popcon scores should include a rationalle about why the two scores are comparable. For example, gnome-terminal and rxvt are somewhat comparable since they are both terminal emulators. But, only the vote scores, not the inst scores should be compared, since gnome-terminal is installed by default. dhcp3-client and udhcpc are not comparable despite being similar packages.
popcon scores do not measure long tail effects
A strength of Debian is that not only commonly used, but also uncommon and niche software is packaged. Popcon does not measure the benefit of some little used peice of software being there, packaged and ready to use when a user needs it.
For six years I kept satutils in Debian, despite it probably having no users. It has a very specific use case, to control a motorized internet satellite dish typically installed on an RV. I did that because it was essentially no work (the package was approximatly bug free, and required no changes since 2007), and because of the possible payoff if someone needed this thing and there it was, in Debian. The value of Debian in that occasion would spike to a value that, while not directly comparable with a popcon score, would be pretty epic, for that one user, as they pushed arrow keys to move a satellite dish around.
(It also had the best WITHOUT WARRANTY statement I've had the pleasure to write: "If you break your dish off your vechicle using this software, you get to keep both pieces.")
Every removal of a package for "low popcon score" runs the risk of silently degrading this overall value of Debian.
who wants to be popular?
Part of the problem is that popcon has been around long enough that the connotations of its name, "popularity contest" have been dulled by repetition (and abbreviation). Popularity contests are not pleasant things. They rarely reach the best result. They embody the tyranny of the majority. The name was originally, to the best of my knowledge, chosen exactly to imply all these failings, to say that hey, popularity-contest is deeply flawed, but is better than nothing for this one specific use case (ordering packages to place on CD sets). We no longer think of popcon with these caveats. That is a regression in your brain. Fix it.
By removing packages that appear unpopular, we run the risk of Debian becoming bland and homogenous.
I was given this Sheevaplug. The idea with plug computers is they look like just a wall wart, but are a whole computer. Ideally, a FreedomBox. The wall wart computer concept doesn't entirely work for me because first, I don't like socket blocking wall warts, and secondly, I'm living in the island of Offgridistan with its weird 12 volt wall sockets.
Solution was to convert it to be USB powered. This is easy because the Sheevaplug's built-in power supply runs it at 5 volts.
 |
The USB power cable was conveniently routed in through a clip that
holds the power socket in place. Bonus: The clip lets the cable
be pushed in, but not pulled out, which avoids strain on the connection.
Then it's just a matter of connecting the obvious wires. (I couldn't find a 4 pin connector on short notice so I reluctantly cut the short cord from the AC power supply.)
I'd probably not want to fly with the result (want to install a proper USB socket for power to avoid the dangling exposed wire effect), but it's otherwise pretty perfect.
I've replaced my nslu2 wifi/dialup/cache/mpd box with the Sheevaplug, and the massively increased memory and speed, at nearly the same power, is a nice improvement.
I did run into two weird issues. I have to use a USB stick for storage, since both SDHC cards I tried, a 16 gb Transcend and a 1 gb no-name had lots of IO errors (error -110). I don't seem to be the first to encounter that, but there is not a sure workaround, although recompiling the kernel wirth high speed SD disabled might fix it.
Also, u-boot refused to boot from my USB stick when I used one USB hub; with a different hub it worked ok.
Alphabetical order's not nice
But use it if no others suffice.
Can you think of a way to
Do better?
Each manual page option sorted, not by its
First letter, but
Grouped in a sequence, by sense.
Highly structured, to be scanned at a glance!
I think that is better, and "So Say We All".
Just think of the savings, in time for us all.
Kaleidoscopic knowledge, swirled around, then
Left to sit, on the page alone,
Makes me wish that in kindergarten,
No ABCs graced the top of the classroom.
Only... it's true, in printed
Pages of text,
Queries are satisfied best by
Running ones finger along, in order,
Stopping at the word one desires.
Truth. But...
Until these days of glittering screens and even e-ink pass,
Vacently staring at text all in order, or smudging the screen, is not best.
Wikipedia alphabetical? Surely you jest!
Xenophobia is best hyperlinked; not followed by xylophonists.
Years from now, will we care about
Zany alphabets? (Unicode could take this to a higher plane, but I'll stop here.)
Inspired by: Debian bug #499487 Debian bug #551741 Debian bug #561017 Debian bug #623890 and many more.