screen is really simple to use, but it can be hard to get started. It has so many features that the essentials get lost if you try (say) to read the manual. So here they are:

1: Start a new session with screen

This is the first thing to do, but it’s confusing, because when you do it you just get a shell prompt again. What happened? You’re actually in a new shell, inside of screen. To demonstrate, start a long-running command, like cat. Leave it up, and go on to

2: Detach from inside screen with “Ctrl-A d”

You should get a message saying screen detached and a shell prompt. This is the prompt from your old shell: It actually ran the command screen, the stuff between then and now was all inside screen, and now the screen command just exited and we’re back at the old shell. Now you can do whatever, log off, log back in, just don’t reboot, then

3: Reattach screen with screen -r

Hey, hey, we’re back where we were when we ran screen in step 1, and our cat is still there waiting for input! That’s the most fundamental concept, the core of screen: It keeps these pseudo-terminals going for you, while you log off, go to bed, switch computers, whatever. There’s a parent “SCREEN” process that screen made, and as long as that process sticks around, you can go back to your pseudo-terminals with screen -r. There’s one other fundamental:

4: Detach from outside screen with screen -d

When you try to reattach a session which screen already has attached elsewhere, it gives you an error. (Try it from another shell.) Maybe the network kills your connection while you’re in screen. Maybe you absent mindedly left it attached from visiting the Timbuktu regional office. Maybe you had to leave in a hurry and couldn’t do petty housekeeping like detaching your session. But you need to reattach that session here. So screen -d will detach the old connection, and now you can screen -r freely. Try it!

That’s the ultra-basics. When you’re comfortable with them, you can read about how to do copy and paste, multiple windows, multi-display, and lots of other useful features… At leisure. You’ve got the core now.

In C, you only have call-by-value (with some wierdness for arrays). To pass a reference, you explicitly take the variable’s address. This has the benefit that you can easily tell a function call which won’t modify a variable from one which probably will:
  int i;
  f(i); /* i is unchanged */
  g(&i); /* i is likely changed */
However, for composite types, you often want to avoid making a copy when you’re not modifying the variable, so you end up with a function h(const T*) which is called as h(&x) anyway.

C++ adds call-by-reference, so that a call which looks like f(i) no longer tells you that i isn’t modified. This is a shame. Some style rules will give you the benefit of being able to tell modifying from non-modifying functions, while still getting the copy avoidance without burdening the caller with that implementation detail:
  f(T x) /* Call by value: x is a local copy. Use this when you want to play with x's value in f() without affecting the caller. */
  f(const T x) /* Call by value: x is a local copy and const. Use this for easily copied types which f() will only be reading. */
  f(T& x) /* Call by reference: x is shared with the caller and modifyable. Avoid this. */
  f(const T& x) /* Call by reference: x is shared with the caller but not modifyable. Use this for composite types which you don't want to gratuitously copy. Because x is const to f(), the caller can pretty much treat it as if f() got a copy. (The gotcha is that f() has to be aware that it'll see modifications to x made through other references, unlike with a copy.) */
  f(T* x) /* Call by pointer: Use when you want to have f() modify *x for the caller. */
  f(const T* x) /* Call by pointer, but not modifyable through it. Avoid without good casue, as this is generally semantically a call-by-reference. */

With the f(T&) case gone, we once again can be confident that f(i) won’t change i but g(&i) is likely to. More likely than with the C rules even, because we prefer f(const T&) to f(const T*) in cases where we’re merely using pointers to avoid an expensive copy. Pretty nice. Now I just need wide adoption and lint enforcement.

Hmm, been a while since I put anything here. How about a tip o’ the month?

Say your graphics card gets all wonky, but you still have a lot of state in your X session which you don’t want to lose. A good thing to try is “sudo chvt 1” to switch to a text console. Then when you bring X back with Alt-F7 or whatever, the X server shifts the card back into graphics mode from a clean slate and then displays everything you have up. Of course, it doesn’t work if it’s the X server itself which is messed up, or if the card’s state is too far gone to switch to text and back.

After a crash, do you get messages saying firefox is already running and to shut down your old instance before starting up a new one? You need to delete the invisible “.parentlock” file in ~/.mozilla/firefox/$profile. It might also help to kill any gconfd processes and remove any files named ior anywhere under ~/.gconf (find them with find ~/.gconf -name ior).

Why can’t these apps store some kind of host-process identifier in their lockfiles, so they can detect staleness? (See eg. screen, which easily distinguishes local-live, local-dead, and remote.) gconfd is especially annoying, because it doesn’t report the errors except to the syslog, so the user just gets the mysterious symptom of their configuration settings disappearing.

The shell reads scripts in as it runs, and not even nicely line-by-line, so when you modify a running script, weird things can happen as the shell gets inconsistent versions. Usually this just results in harmless errors like “/home/jlxmodmap not found”, but if you’re like me you worry about “rm tmpfile; process importantfile” turning into “rm importantfile”. The usual technique for the paranoid is to “mv script script.old; cp script.old script”; the shell sees the old script, which you keep unmodified, while you edit the copy. But it’d be nice if you didn’t have to do this everytime…

So, someone told me the trick of having all the work a script does happen in a shell function, which you call at the end of your script. I’m using this for my .xsession (canonical example of a script modified while it’s running), which looks like:

main() {
  do stuff
  do more stuff
  do even more stuff
  exit
}
 
main

voilà. It’s already read in all of main() by the time it runs it, so you can modify it freely, except when it’s just starting up and parsing things.

The locking in Berkeley DB is fundamentally broken.

This isn’t something that’s bitten me recently, but talk about it did come up recently, and many BDB users are unaware of the problem. It’s especially surprising when you first encounter it because BDB is so solidly done in the rest of its implementation and the problem isn’t advertised. Of course locking will work — everything else does!

The problem is that BDB locks are bare mutexs, and no forcible release mechanism is provided. There is no way to rollback to a state before a lock was acquired. There is no way to retry. You take the lock, do your modifications, and release. Or you take the lock, do some of your modifications, and the circuit breaker trips, power is quickly restored, the server reboots, and now your BDB is hosed. You can’t take the lock because BDB thinks your old instance has it. You can’t release the lock because you don’t have it. If you could release the lock, your database is inconsistent because you can’t rollback. The only way you can do anything is to blow away the BDB environment and make a new one (suffering collateral damage when you just want to destroy a mere lock) and hope that the partial transaction you’re unleashing as a result isn’t a problem (and if it isn’t, why did you need a lock?).

So, what can you do? You can try to build your own transaction system on top of BDB, but that’s a lot of work. A lot of work, when there’s better featured databases out there already. If you were using BDB and need more, MySQL is probably good enough for you. It has partial transaction support (probably more than you want to write!), and does have a library implementation (libmysqld) so you can avoid running a server and just use data files, like in BDB. If you need full transaction support (good luck implementing that on your own), there’s always ye olde enterprise-grade PostgreSQL. Or maybe you don’t need transactions after all? Then Berkeley DB is solid as a brick.

So, the firefox logo makes sense.

A fox, with a firey look. Cool logo.

But what’s that thing behind the fox? Well, with the Deer Park logo, we get a better look.

But if you look closely, you see that the shapes on the FF globe don’t match those on the DP globe. And they don’t look like the continents I know. Maybe it’s just an ordinary circle with abstract shapes? But it’s shaded like a globe. Is it one of those funky extrasolar planets? (They’re planning a Galaxy Wide Web!)

I think I preferred the fox. I also liked the old Red Star mozilla logo, not so much the dino head or the big “m”. And don’t get me started on the ship steering wheel or the big “N”. Even the old NCSA Mosaic logo was better than those.

Why does every iteration of the product need a new logo? Doesn’t seem like the best way to build brand awareness. Compare:

Firefox 1.5 beta 1 (“Deer Park”) has just been released.

This was good timing for me, as I’d just updated GTK+ from 2.4.14 to 2.8.3 in order to get GnomeMeeting working, and that had broken Firefox 1.0PR, so I was back to using the old Mozilla 1.7 I had lying around.

Download pre-built versions at http://www.mozilla.org/projects/firefox/ or build it yourself from the source at http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5b1/source/

This will unpack into a directory named “mozilla”, so be careful about clobbering other mozilla builds if you have them. Build directions are at http://www.mozilla.org/build/

The “Starting the Build” directions didn’t work for me, instead I had to do what it has under the box: cd $objdir; ../configure; make

Oh, and the tarball it makes from make -C $objdir/browser/installer is tagged “1.4” still, but that’s minor enough. Now I just need for the extentions and “themes” (skins) to be updated.

I promised you a more upbeast post, so here it is…

Work recently gave me two very nice LCD monitors to replace those I’d been using before. 24″ TFT from Dell.

“Unfortunately”, the graphics card in the desktop I had (which I’d been using since getting hired) couldn’t drive these things, so they gave me a HP xw4200 to replace my xw4100, double the RAM and faster processor.

Now my computer can display on my monitors, but side by side things are very wide. But, these monitors can rotate on their stands! (Couldn’t do that with my old ones.) So, I want them vertical and side by side. Well, someone else had done the hard work of figuring out how to make that work, so I went and followed his lead. The distillation of that came down to:

• Install the x.org X server (this deserves a post in itself)
• Edit xorg.conf, turning off Xinerama and turning on xrandr (for now they’re incompatible):
  • In the “Device” Section, add Option "NoTwinViewXineramaInfo" "on"
    and Option "RandRRotation" "on"
  • Change TwinViewOrientation to “Above” or “Below”
  • In the “ServerLayout” Section, add Option "Xinerama" "off"
• Put xrandr -o left at the start of your .xsession

Before and after screen shots at 1/8 scale:

I finally have enough space to have all the xterms I want! I’ve been trying to reach this state since forever, first with screen then with just piling the xterms onto all the real estate I could get. I don’t have to drop context and have space left over now. It’s surprising how good this feels– It’s this slight pressure that I never really noticed, the small frustation of having to look for somewhere to type– gone.

Okay, so I now have WordPress working with suphp, which allows for the use of Unix user accounts in php scripts. Steps:

• I made a dedicated jlmphp account, so php won’t have access to my main account.
• The hosting server (ofb.net) runs Debian, so I installed suphp with
  apt-get install libapache-mod-suphp
• In the Apache config, I put the lines:
  

  LoadModule suphp_module /usr/lib/apache/1.3/mod_suphp.so
  suPHP_Engine on

  and

  <VirtualHost *>
  ServerName php.mandelson.org
  DocumentRoot /home/jlmphp/www/data/
  </VirtualHost>

  The first set turns suphp on, the second set makes a virtual host “php.mandelson.org” with its own www directiory in jlmphp’s homedir.

• Made a CNAME aliasing php.mandelson.org to mandelson.org, so that when you look up php.mandelson.org you get this server.
• Changed the blog address to be http://php.mandelson.org/wordpress/
• In the .htaccess file for jlmphp, put
  

  AddHandler x-httpd-php .php

  (which tells Apache to use suphp for .php files in this directory), and put in redirects from the old blog address to the new.

• Made wp-config.php user-readable-only and change the passwords. (Which is the whole point!)