Facebook: lying liars. Water: wet.

Hey, remember when I said:

Hey, remember when Facebook's hateful "real names" policy got a lot of press because they went nuclear on a bunch of queens? And then they put out a contentless, fawning press release with a fauxpology in it?

And remember when they then they got a ton of shamefully credulous press from people saying, "Well, that's all better then"?

And remember when people like me said, "You know, maybe you should save your applause for after they've changed either their official policy or their demonstrated behavior, or both, because they haven't", and nobody listened?

Well guess what, it took seven months, but said drag queens have finally noticed that Facebook's bullshit was bullshit. Now they have a petition to ban Facebook from the SF and NY Pride parades. Which you should probably sign, because why the hell not. Anything that causes discomfort to their PR flacks can't be bad.

Previously, previously, previously, previously, previously, previously, previously, previously, previously.

Tags: , , , , , ,

Teacher Week: Honest stickers for underachievers.

Previously, previously, previously, previously.

Tags: ,


Windows 10 gives users the finger with new emojis

Unicode 7.0, standardized last June, added 2,834 new symbols to its lexicon. Around 250 of these were emoji, and operating systems have been updated in the months since to include support for many of these new pictograms.

However, one of the Unicode 7.0 emoji has gone unimplemented: the catchily named "Reversed Hand With Middle Finger Extended," codepoint U+1F595. Or as it's known in common parlance, the finger.

iOS, OS X, and Android all omit this important and expressive gesture. The emoji obsessives of Emojipedia, however, noticed that Windows 10 bucks the trend and includes support for the one finger salute. As with other emojis representing humans and their body parts, the flip the bird emoji supports Unicode skin color. By default, it uses a non-human tone -- Windows 10 uses grey for this, in contrast to iOS's Simpsonesque yellow -- but it can also be shown with a variety of roughly humanoid skin tones.

Previously, previously, previously, previously, previously.

Tags: , ,

100 Years of Cocktails in under 2 Minutes

Previously, previously, previously, previously, previously, previously, previously, previously.

Tags: ,

Star Wars: The Binks Awakens

[ beeps despondently ]

Previously, previously, previously.

Tags: , , ,

DNA Lounge update

DNA Lounge update, wherein the Empire expands again.

git and backups

Dear Lazyweb, how can I tune git to make it be more amenable to rsync-based backups?

I do my backups with rsync from the root directory, as is right and proper. One of my machines has a dozen git repositories scattered around its file system in various places. This machine's backup target is at the other end of a not-fast connection.

And, git's data model seems to be "I'm going to continuously make 100% changes to multiple 50+ MB files, to ensure that there's nothing incremental about your incremental backups."

Is there any way to tune git's file usage to be less egregious? Do "git gc" and "git repack" make this worse, or better?

You're about to suggest that I not back up my git repositories, but just do a dozen different git checkouts on the backup-target machine instead. No. Let's just leave it at "no" so that I don't have to explain the several different ways in which that suggestion is stupid.

Kinda missing CVS right now.

Update: Unless I missed something, there have been 3½ suggestions here:

  1. Turn off pack files and gc entirely, which will cause small files to accumulate for every future change, and will eventually make things get slow. gc.auto 0, gc.autopacklimit 0.

  2. Set the maximum pack size to a smaller number, so that no pack file gets too large, and subsequent layers of diffs get bundled into smaller pack files. pack.packSizeLimit.

  3. Dissenting opinion on #2: That doesn't do what you think it does, it just slices a single large pack file into N different files with the same bits in them, so you haven't saved anything.

  4. If you already have one gigantic pack file, create a .keep file next to it. New pack files will appear but they will be diffs against that saved one, and thus smaller.

I guess option #4 is the only practical one?

Previously, previously, previously.

Tags: , , ,

  • Previously