Entries Tagged 'Computers' ↓

Apple has never impressed me with their ability to have two different devices synchronize with each other. But they’ve got plenty of hubris, so they keep trying. Take the app store. (Please!) Here’s what happens when I sync my iPad: it tells me I need to authorize my computer to sync to it, I authorize it, and then it tells me never mind, because the computer is already authorized.

OK. That explains it, then.

Terra Terminal Emulator. For people who rebel against learning to use Screen. We’ve come a long way from the ADM-3A.

I quit using Linux (except as a file server) almost 10 years ago, so I completely missed the Desktop wars. Apparently KDE and Gnome won, with Gnome winning the part of the Linuxphere known as Ubuntu. Which leads to all kinds of out of date help pages telling you how you used to administer a Ubuntu system (“From System Administration choose Disk Utilities”). Along with a fair few pages complaining how Gnome 2 was better, or Gnome 3 was bad but 3.6 fixed most of the problems, or whatever.

As may be. I’m a crusty old bearded Unix user, from the era of Window Managers rather than Desktop Environments. (Well, CDE begat KDE, so I guess there were Desktop Environments even back in those days, but I never worried about them.) For me, it was a big deal (with no small amount of editing config files) to move from FVWM to WindowMaker.

So what do I do? I don’t know. But I’m thinking about Xubuntu and XFCE. How’s that for rebellion? You say you want a revolution!

My last post on rbenv mentioned some things you need to do to get ruby to build on Mountain Lion. Here are a few more things.

This guy Jacob Swanner didn’t want to use either Xcode or gcc. He just used the Xcode command-line tools, with a CC environment variable, thus:

$ CC=/usr/bin/clang rbenv install 1.9.3-p194
$ rbenv global 1.9.3-p194

That won’t work with older versions of Ruby, however, as I mentioned before.

I noted he is also a Homebrew user. I’m not yet ready to go there, although macports gets more and more frustrating with each OS release. (I’m not alone.) (But that’s a subject for some other time.)

And, for convenience, here’s another Homebrewer’s notes on how to get ruby building again with Mountain Lion

I used to use rvm to manage my ruby environment, but the latest hotness seems to be rbenv. Here are some tips about using it. They’re aimed at me, because by the next time I need to use it, I’ll have forgotten. But you can read them too:

One of the things you want is rbenv-build:

Installing ruby-build as an rbenv plugin will give you access to the rbenv install command.

$ mkdir -p ~/.rbenv/plugins
$ cd ~/.rbenv/plugins
$ git clone git://github.com/sstephenson/ruby-build.git

(Note the assumption you’re using git. I don’t know what people who prefer mercurial are supposed to do.)

This will install the latest development version of ruby-build into the ~/.rbenv/plugins/ruby-build directory. From that directory, you can check out a specific release tag. To update ruby-build, run git pull to download the latest changes.

But that won’t work with Mountain Lion. So you’ll need a version of ruby that can be built with clang.

$ rbenv install 1.9.3-p125
>

In a previous posting, I said I had problems connecting with more than one Google calendar per Google app.

I assumed that was a misfeature of the syncing capability of the iOS calendar apps. But I was wrong.

The problem was with Google — or, really, with me.

Google provides an interface called iPhone Select. If you want to sync more than just a single calendar with your iOS devices, you have to change a setting there. (By “there” I mean in the iPhone Select interface. You can’t change it in the regular Google Calendar settings page.)

You can find out more about iPhone Select here.

Kudus to BusyMac, which alerted me to this feature of Google Apps when I actually RTFM‘ed their documentation.

Update: I’ve figured this out. The problem wasn’t with Apple at all. I was wrong to assume it was at their end, and even more wrong to assume the problem would never be fixed due to the poor state of relations between Apple and Google. I was wrong and I’m sorry.</update>

I’m having trouble with Calendar syncing in Mountain Lion. It works with multiple Google-Apps accounts, so long as they just have a single calendar apiece. Typical version 1.0 Apple junk. Maybe someday it will work,   Continue reading →

I found this program called Cathode that does an incredible job of recreating the experience of writing code on a CRT display, ca. 1980–83. Many was the hour I logged on the Lear-Sigler ADM-3A — in those days time was logged, so you could pay for it. That was incredibly unfair since the I/O (for l’users) was throttled down to 4800 baud.

Check it out. Then give it up, before the ergonomics make you blind.

As a sort of colophon, the code I’m editing here is genuine K&R C, from the Old Testament. There are two anachronisms:

1. I’m using vi to edit it, but in the day I was busy getting all carpal with emacs. I had no choice here: there might be an Emacs on my system, but if there is, I can’t remember how to get out.
2. I wrote this code in 1992, by which time we used terminal emulators like Kermit on PCs, instead of real terminals. However, it was a recreation of something I wrote in about 1983 to translate English into “Klingonese.” (Not the stuff used by Star Trek fans. That came later. I’m talking STA KANG, PUSHJ JRST.)

To be fair, I don’t think I ever wrote C on the ADM-3A, or even a VT-100. I don’t think the DECSystem-20 even had a C compiler. All my C was on the VAX, which had HP-2621A terminals.

In my previous entry about passwords, I didn’t say how hard it would be to crack my passwords. Beats me. I didn’t even say how many bits of entropy they represent, which is apparently what all the cool crypto cats do.

(The first number I cited, 3 × 1 million³, has 62 bits(!) of entropy. That’s a tough nut to crack. My least-secure option I said was from a pool of 425 million passwords. That’s only 29 bits, which is still about twice as secure as the passwords people suggest you use, things like Tr0ub4dor&3.)

The reason I didn’t cite bits of entropy is (first, that I don’t know math, but secondly) because I’m more interested in the size of the password pool. That is, if you knew the set of common words I’m using (you don’t, but you could start here), how many different separators I use, and the rules for combining them, there are that many possible outcomes.

My pool-size numbers are conservative, because a cracker doesn’t know (for sure) if I’m using only legal words, much less common ones. For all the would-be cracker knows, my dictionary could be full of gibberish like you get from pwgen(1):

iquifeer  nosubiek  iungeime
eighaeka  aqueejas  oaxepohb
aequahsa  raingaej  azeefeep
johphaec  fahtieda  aihaimif
aduyoowe  airahbop  iedeibae

I might even be using pwgen’s “hard” settings:

jjfidv7B  8ZbBAEMP  9zR5PBPn
8f45kjMB  bWZiOF6j  3P7t4FLY
Y1iZKeYA  z8k0nv1T  WD3yQcW8
nDyVSe5o  k42muCy2  F7W43IFD
u2pGNV8F  fQ0CvvT7  k7awERR1

I wouldn’t do that, because those passwords would be hard for me to remember. But how does the cracker know that?

In the spirit of the XKCD cartoon, I’ve written a tool to help me think of really secure, really memorable passwords.

For example, here is a set of 5 such passwords chosen at random from a pool of 3 million million million passwords:

starkly.scoop.drawer.gifted.become
stack.epilogue.surprise.print.ancillary
beast.incentive.cloud.country.magical
practiced.original.sinusitis.low-wage.widowed
snarl.ritual.trouble.power.shoreline

But that’s a lot of typing. If you’re willing to be less secure, here are 5 sample passwords chosen at random from a much smaller set of just 625 million million passwords:

likely.crippling.digital.distrust
clogged.gaiety.earth.bring
ragged.online.house.suppose
wordplay.golden.humbling.adviser
untimely.plenty.all-pro.cancer

Still too much typing? How about these 5 super-easy passwords chosen at random from a set of just 425 million passwords:

brawl@social
surrender;newsman
parallel&thwarted
comedic*effort
flooring>brutal