Saturday, January 31, 2004

Today I installed the Hurd

It was not a success.

I took a clean drive and installed in a newly acquired 1U server. It had been hosting Twisted Matrix's website until recently, when it began to suffer from overheating. Case open, next to my other machines, it seems to be alright, but the fan is obscenely loud. Then I installed Debian/Linux, since there is no bootstrap installer for GNU/Hurd. Then I went ahead with GNU/Hurd.

The install wasn't that bad. I screwed up three times before I got it right, once because I didn't read carefully enough and rebooted improperly, and twice because, for whatever reason, mke2fs on Linux didn't generate a filesystem the Hurd could handle.

Getting the network up was a breeze, just one somewhat strange command. No DHCP support, apparently, but luckily my network could handle a random new IP showing up. Installing software was easy, of course. Just apt-get away.

My original goal was to see if any of Twisted's unit tests passed. I installed Python, but apparently the most recent version was 2.3a0, which had plenty of bugs (although none that I think Twisted's unit tests tickle, but who knows?). Before it even ran any, though, segfault and core dump. Woops.

Getting Twisted itself also brought up a minor bump. There is no random device on the Hurd, unless you configure one yourself. #hurd on told me there was no standard translator (a translator, as far as I can tell, takes a device file and makes it do something useful) for this, and I couldn't bring myself to download a random translator from the web, build, and install it. These are essentially kernel modules, after all. So I suffered the lack of ssh and did a pserver checkout of Twisted instead.

Since no unit tests passed, I figured I'd go back and figure out what the story with Python versions was. One apt-get install links later, another segfault. Unable to browse the web, run Twisted apps, or ssh, I began to lose interest. #hurd assured me that these segfaults were not a normal occurrence, so I might have simply misconfigured something. Who knows? Perhaps I'll try to examine the core dumps with gdb, but debian doesn't make it too simple to get debug versions of most things, and the criminally loud fan is amazingly annoying, so who knows if I'll actually follow through.

Friday, January 30, 2004


I had the longest talk about unions I've ever had with my mom tonight. She's an advocate for a collective bargaining unit. Someone I know [details omitted] has a pretty crummy job at [details omitted] I've been trying to convince her to get unionized.

I was amazed at the level of covert activities involved in getting a non-union shop unionized. I knew there was a lot of hostility toward unions, but I guess I didn't realize just how much.

Meetings are held in secret for as long as possible. Management generally tries to get a mole in as soon as they suspect any organization is going on. An important part of being successful is figuring out who in the group of employees likely to be working for management and excluding them from the process.

Law requires that once 30% of employees indicate a desire to organize, a vote must be taken to determine if collective bargaining will take place. The vote requires better than 50% support to pass, of course, so many unions wait until they have a higher level of support, often 70%, before they spill the secret that they've been trying to organize.

Once management knows a vote is pending, they generally do anything they can to convince employees to vote against it. Campaigns to sway employee opinion away from the union position are started. Tactics like mandatory "training" sessions, where anti-union videos are presented, are used. Some people get raises or promotions, to convince them they don't need a union. Other people get fired, to show the rest what will happen if they support organization. It is illegal to fire employees for attempting to unionize, but proving motivation is often difficult, and even if you can prove it, those laid off aren't always fully compensated. For example, eight people were fired from the last company my mom worked to organize. Even though it was found that they were fired illegally, they only received 70% back pay. They were not rehired, they weren't given any other benefits.

And those who are fired don't get to participate in the vote. If management succeeds in bribing (or otherwise convincing) or firing enough people, the vote fails and collective bargaining isn't allowed.

So anyway, I just wanted to capture some of what I learned tonight, depressing though it may be.

Monday, January 26, 2004

Two lessons learned

Premature synchronization is the root of all evil:

No matter how sure you are that part of an interface will never need to block, you are wrong. Even the simplest task will be expensive or slow for someone, at some point. Design interfaces to deal with asynchronous responses from the start. How did I learn this? I designed a mailbox framework and make the "select mailbox" operation synchronous, almost alone among the 30 or so other functions in the interface, because I was certain it was such a simple operation it would never need to block.

Loading data is expensive; loading unnecessary data is inefficient:

For the sake of simplicity, the "list all mailboxes" operation was implemented in terms of objects already defined by the interface. Specifically, it was defined to return a list of mailboxes, but only a few fields of each mailbox are ever actually used. How did I learn this? Tonight discovered that my implementation of this operation ran over ten thousand times faster if the implementation only returned the required data, instead of whole mailbox objects. Oops.