September 28, 2004
or maybe there was a banana in his ear

George Colony, CEO of Forrester Research, recently described Sun’s “fighting chance” strategy for recovery, as told to him by Jonathan Schwartz, including this first step:

Step No. 1: Make the argument that Linux equals Red Hat. … Sun’s view is that Linux is nothing more than Red Hat.

But some three weeks before, Jonathan himself decried that very attitude:

And Red Hat is not linux, despite what they say, and despite what the media (and IBM’s ads) seem to conflate. … Let’s start calling a distro a distro.

This doesn’t strike me as the sort of misinterpretation that one would expect to arise from a conversation between the CEO of one of the industry’s most influential analyst firms and the president/COO of Sun Microsystems. I wonder why Sun didn’t make them post a correction.

Posted by shaver at 07:46 PM | Comments (1) | TrackBack
July 19, 2004
careful what you wish for

The case for: if you separate mechanism sufficiently from policy, people can use that mechanism to implement arbitrary policies.

The case against: if you separate mechanism sufficiently from policy, people will use that mechanism to implement very arbitrary policies.

Je vous remercie pour votre attention.

Posted by shaver at 10:54 AM | Comments (5) | TrackBack
July 04, 2004
the relentless march of progress

From various channels, early this morning:

* bryner is really disturbed by redhat's gcc 3.3.3 (fc2) generating worse code than their 3.3.2 in fc1

< vlad> vladimir@tornado[1099]% rpm -q gcc34
< vlad> gcc34-3.4.0-1
< vlad> who needs 3.3.3?

< shaver> use gcc34?
< bryner> it's even worse

Posted by shaver at 03:12 AM | Comments (2) | TrackBack
June 19, 2004
inside out

Nat’s right, the TCPA’s agenda sucks. I wonder if his position as an executive at a company that holds membership in the TCPA will let him do some good. That would be pretty awesome.

Posted by shaver at 03:27 PM | Comments (0) | TrackBack
swinging both ways

Havoc posts some interesting thoughts about dependency evolution in Linux distributions, but I think he misrepresents the state of Mozilla installation:

The big previously-proprietary apps such as OpenOffice.org and Mozilla have a very different attitude and tend to assume end users will install the app themselves. Which is both true and untrue on Linux; some will try the app themselves, and some will get it with their distribution.

Mozilla (and Firefox and Thunderbird, even in their pre-1.0 states) will work just fine if you just untar it in your home directory to test a new version, and it’ll work just fine if you have your admin install an RPM of it. We even now support adding most kinds of extensions and browser plugins on either a per-user or system-wide basis, if you find — as many do — that you want to add something beyond what’s in the usual packages.

Installing a new version of GNOME to test it is much, much harder — or to develop against it, should you want to listen to people crying for better GNOME integration in your multi-million-user desktop app, just to pick an example at random. Harder than I can often manage, and I have a bit of a reputation in these parts for knowing my way around software.

I guess that’s

correct for a desktop platform

though. *wink*

In almost-unrelated news, bryner is waging a hero’s battle against broken GTK theming implementations (in both themes and the GTK core, as I understand it) to deliver pixel-perfect native control rendering for GTK in upcoming Firefox releases. In your honour, my good man, I raise a glass.

(I’ll leave the “previously-proprietary” comment, mostly, but there is virtually nothing about the Mozilla build or install system that’s left over from its life as a closed-source app, so I’m not sure how he intends that to relate to this issue.)

Posted by shaver at 02:18 AM | Comments (2) | TrackBack
June 07, 2004
not so fast

ITNews and MacDailyNews seem quite enthused about the prospects opened up by Apple shipping the Safari WebKit as part of iTunes on Windows. Just one problem: it’s not true.

As Hyatt comments in the MacDailyNews, iTunes just ships QuickTime, and there’s no WebKit in it at all. Nice thought, though!

(Also, Safari, while nice, is definitely not the most standards-compliant browser out there. If it’s not Mozilla, it’s Opera.)

Posted by shaver at 01:46 AM | Comments (1) | TrackBack
June 02, 2004
connecting (housekeeping)

There’s a kind gentleman here right now setting me up with one of his spare TiVos, along with a small pile of software so that I can pretend to be the TiVo guide service, and use the zap2it channel data as my back-end. It’s been an adventure, but it’ll be all worth it

Especially tomorrow, when I have an ultimate game that will bump into Game 5. Sweet, sweet buffer.

Posted by shaver at 08:21 PM | Comments (2) | TrackBack
May 20, 2004
a knife at a tank battle

Seth Nickell’s a decent guy, and I think his insights on the design process are often deserving of careful consideration.

But when it comes to analysis of patent risks for various technologies, he is very much out of his league.

I have lots of thoughts about the Mono patent issue, and I will share them here in more detail once I finish up with my responsibilities for this week. I think that Nat highlights the most common failing of critical thinking in this debate, though: there is no “safe” choice, and I have not heard any compelling arguments to make me believe that any of the proposed alternatives are any safer. Certainly, the oft-trumpted Java — into which Red Hat is piling quite a bit of money — is not free of patent concerns, and the key patent issues in the next 5 years are going to be application-level ones, IMO.

I am not, of course, speaking for Oracle or the Mozilla Foundation. I mean, honestly now.

Posted by shaver at 04:51 PM | Comments (0) | TrackBack
May 08, 2004
it glows like beauty, on my desk

The monitor that I coveted so has arrived, on the wings of my own personal cross-border monitor angel. It is, truly, a thing of beauty. Even Tyla thinks so.

The ZDNet review review — you will have to scroll down past the acre of ad-garbage, likely — claims that it has “mediocre image quality”, in which case I don’t think I’m emotionally equipped to deal with superior image quality.

(I just caught myself admiring the brightness and rich colours in a banner ad. I’m so damaged.)

Update: *swoon*

Posted by shaver at 11:08 AM | Comments (2) | TrackBack
April 06, 2004
moire-coloured glasses

The monitor at home is starting to make these periodic colour-and-brightness shifts that lead me to believe that it’s on its way out. I’d like to buy one of these little babiesZach, Phil and the boys at AnandTech really like theirs — but Tyla says I have to find a new job before I can do that.

She’s no fun at all.

Posted by shaver at 06:05 PM | Comments (7) | TrackBack
March 07, 2004
calling all cars

If someone out there can tell me how to display JS errors in Konqueror, preferably the version that comes with Fedora Core 11, I would appreciate it. Otherwise, I think I have to buy a Mac, or something.

Other than that, though, I’m getting quite a bit done with the web management tool, and for a web UI I think it’s really quite pleasant to use. And with the schedule I’m on for this thing, I will totally settle for being the tallest pygmy. Even gd’s little problem switching line colours with antialiasing turned on — or so the problem seems to be, to me — can’t get me down.

1 kdebase-3.1.4-6

Posted by shaver at 11:02 PM | Comments (6) | TrackBack
February 29, 2004
chain of causality

I’ve learned some more about the events that led to the impromptu system reinstall, and they’re not entirely amusing, or entirely surprising. Let me lay out a scenario for you.

Let us define E and N as two computer systems, not equal to bitchcake (B).

E was compromised, and a trojan ssh was installed on their system. Via one or more users shared between E and N, N was eventually compromised. (I suspect, though have no evidence to support, that one of the recent flurry of privilege escalation bugs in the Linux kernel let the intruder up the ante on E, N and eventually B.)

N and B also share at least one (likely precisely one) user, and it’s not at all unlikely that this was the vector through which B (and, transitively, one additional machine) was compromised.

This wouldn’t be all that bad, as These Things Do Happen, and I could have certainly done a better job of keeping B’s update, well, up-to-date, but it turns out that E’s administrators knew quite some time before the NB attack that they had this problem, and didn’t bother to tell people. A-frigging-hem. Given that the NB user is conscientious about such things to a fault, and generally the sort of responsible user that every system administrator would like to clone throughout his or her shadow file, it seems not unlikely that we’d have at least discovered the intrusion on B earlier, and quite possibly avoided it in the first place. Alas.

B is pretty sad about the whole thing, apparently, because it just killed another drive in its angst:

hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=120582, high=0, low=120582, sector=120582

Yay! More drive shopping!

(Further: the User In Question should not be beating himself up about this at all. Stop it right now.)

Posted by shaver at 09:23 AM | Comments (2) | TrackBack
February 28, 2004
utility infielding

I’ve been hard, hard at work on the Lustre Management Tools again for the last few weeks, and it’s really been a pretty interesting experience. More than most of my other software work, these tools really do cover a pretty tremendous range of software domains, and it’s been a lot of fun pulling them all together.

The basic job of these tools is to provide a convenient, largely web-based interface through which an administrator or fifty can monitor, manage and (lightly) configure their Lustre storage system. In order to do that well, I need to touch a lot of different types of code. In descending pseudo-order of proximity to the user, we have:

  • DHTML and its devil-kin: you can do a lot of pretty cool stuff with HTML and JavaScript and CSS these days, though it’s still not a trivial process to make things work quite the way one wants on all the browsers one cares about, in the face of all the lovely asynchronous elements that make up the interweb. Certainly, we’ve come a long way since the days of NGR and my other early-career web apps, but it still took some clever (IMO) thinking to make sure that the HTML portions of the UI were relatively self-contained, while getting data in a reasonable fashion from…
  • HTTP-driven services: …the core monitoring service, which uses the minimal-but-eminently-serviceable Python BaseHTTPServer capabilities to implement a tiny, self-contained web server. This represents a huge step forward from my original plans (mod_perl or mod_python, with some Apache config-stanza or, worse, a pre-configured Apache package) in that installation is genuinely trivial, and it’s much easier to manage the application state. In addition to the web service, my trusty little master daemon leads a second life as
  • UDP-based collector: which, again, was quite easy to wire up, with the SocketServer.UDPServer bits just lying there begging for me to make use of them. I run a very simple single-threaded poll loop right now, handling either requests for web content (static UI scaffolding or generated-data) or status report packets send from my herd of
  • Featherweight monitoring daemons: In order to get data in a timely and efficient fashion from the collection of servers that provide Lustre storage, I whipped up a tiny little nanodaemon that listens on a well-known port for the collector’s registration message, and then blips out updates about its Lustre services every few seconds, so that we can have an up-to-date view of available space, server throughput, etc. In order to keep this part as lightweight as possible — it’s about 250 lines now, will likely be around 600 when I’m done — I wrote it in good old C99, and hated every minute of it. Having to manually deal with memory allocation and string tokenization and whatnot is a huge drag on productivity, and I find myself wondering if it might not have been more productive in the medium-term to have done it in Python and then ported it to C if and when someone complained tthat it was too big or whatever. We already require Python for
  • (User-space Lustre utilities: A small handful of somewhat, er, organic tools exist for producing the current generation of Lustre config files, and acting on them to insert modules, configure them with the many and wondered and type-unsafe powers of ioctl, dance with the routing tables in the pale moonlight, format underlying filesystems, reverse the process for shutdown, you get the idea. I’ve been poking at these in various ways to expose some (IMO) nicer configuration syntax and reporting, though it’s not clear how much of that work will make it into the first release of these management tools. I’m of the opinion that these tools could, pretty much to a man, stand to be taken behind the woodshed for a few hours, but there are more important fish to fry right now.)
  • Lustre kernel-service data export: some of the data we want to expose, especially as regards the “holistic” Lustre status monitoring elements, are helpfully tracked within Lustre itself, but are not readily accessible to the user-space world in which my collector daemon lives. I’ve been collecting a small list of things that I want to export, either at all or just in a more manageable way, and I’ll probably start poking at that stuff next week. I may have to dive in a little deeper and collect some additional status factoids that we don’t currently track, but I’m hoping not before the first, impending release. Certainly, there’s a lot of interesting visualization and control that we can expose with resorting to that.
Along the way, I’ve also discovered that for OO programming, Python is much more pleasant to work with than Perl. Perl 5 was obviously encumbered by the basics of Perl 4, but dealing with all the @ISA and Exporter and module-packaging nonsense was just way too hairy for me to want to deal with, to say nothing of the lack of robust exceptions. The killer tile was this passage from the perlsub man page:
Method calls are not influenced by prototypes either, because the function to be called is indeterminate at compile time, since the exact code called depends on inheritance.

Now, I’ve spent a lot of time working on and with dynamic languages, so I understand the problem their facing, but still: when two of the language’s most significant “programming in-the-large” features — support for object-orientation and some, any argument checking — are fundamentally incompatible, I find myself sliding the hammer back into the toolbox and looking at my collection of screws in a new light.

There were a handful of other niceties in Python, not the least of which is the handy REPL-esque interactive interpreter, complete with type-diving online help.

(I don’t hate Perl, you don’t have to bring your language wars to the comments for this post, etc.)

Posted by shaver at 10:45 AM | Comments (0) | TrackBack
February 10, 2004
move along, move along

This is not the exciting recap of my travels that you’re all waiting for. This is my contribution to the improvement of the world, specifically that part of the world that keeps Xft apps — such as my beloved Thunderbird — from crashing like a crashy thing because the font cache is out of date.

You have to use a top-secret fc-list incantation


interlude

< blizzard> because the man page is useless
< shaver> utterly
< shaver> not just "somewhat incomplete" useless, but rather "I could cut
          you and leave you to bleed to death by the side of the road"
          useless

to list the files that are expected to be part of your font set, and then yell about the ones that are missing. I present unto you:

: thunderbird; fc-list "" file | less | cut -f1 -d: | \
          while read F; do if [ ! -f $F ]; then echo $F missing; fi; done
/usr/share/fonts/ja/TrueType/kochi-mincho.ttf missing
/usr/share/fonts/ja/TrueType/kochi-gothic.ttf missing
: tmp; sudo rm /usr/share/fonts/ja/TrueType/fonts.cache-1
: tmp; sudo fc-cache

(Repeat the rm@ bit for @fonts.cache-1 files in any other directories implicated.)

Posted by shaver at 05:29 PM | Comments (0) | TrackBack
January 12, 2004
would you mean this please, if it happens

I’ve been thinking about switching the mail system on bitchcake to use maildir instead of mbox format, mainly so that I can use a version of webmail that doesn’t take six months to open my wife’s old inbox. This page makes it sound like a man of even my meagre talents could handle it, and probably without losing anyone’s mail!

Should I be resisting this urge?

Posted by shaver at 07:16 PM | Comments (4) | TrackBack
January 06, 2004
couldn't happen to nicer guys

Mike Hoye is having a bad computer day, for which I have great sympathy. I’m sure he’ll tell us all about it. (I’m mildly inspired to set up something to protect other people from this sort of bad computer day. Wonder if I’ll find the time)

Meanwhile, back at the ranch, Zach is having a wonderful time with some drivers he’s trying to integrate into something or other:

< zab> I would have first identified this code as satire

I almost feel guilty; I had a pretty decent day, myself, though the gym would have been better if I’d eaten more of a breakfast beforehand.

Posted by shaver at 12:46 AM | Comments (3) | TrackBack
January 02, 2004
the longer I'll have to catch up

If I’ve promised some computer-administration task to you in the last little while (likely configuring Movable Type, the way my scribbled post-its look), now would be a good time to remind me. I have a vague feeling of enormous backlog, and can’t remember which favours are yet undone. Humour me; I have a bad movie.

Posted by shaver at 03:56 PM | Comments (1) | TrackBack
December 29, 2003
how rude

I have a large collection of Tragically Hip bootlegs, which I store on this machine for my easy access from work and home and abroad. It’s not linked to from anywhere that I know of, but apparently Google found it. So some guy (199.67.140.76, I don’t love you any more!) was pulling down MP3s as fast as the ISP’s link would take it, which is to say substantially faster than I would have liked. Kids these days, I tell ya.

Posted by shaver at 01:18 PM | Comments (4) | TrackBack
December 24, 2003
friends like these

I have a Word document that I have to read. Sure, it’s just two pages, and it just contains text with no markup whatsoever, but the author used Word to hammer it out, so here I am. In order to view it, I want to install OpenOffice.org on my laptop.

I have at my disposal two tools designed explicitly for the purpose of fetching this sort of software, and its dependencies, with minimal hassle.

In one corner, wearing the trunks with the foul output format and cryptic-even-to-me search interface, yum. Yum likes long walks on the beach, fetching dozens of headers one at a time, and, oh, what’s this?
: work; sudo yum install openoffice.org Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Base
Traceback (most recent call last):
  File “/usr/bin/yum”, line 60, in ?
    yummain.main(sys.argv[1:])
  File “yummain.py”, line 188, in main
  File “clientStuff.py”, line 766, in get_package_info_from_servers
  File “clientStuff.py”, line 103, in HeaderInfoNevralLoad
ValueError: unpack list of wrong size

Well, huh. (I tried updating yum with yum, in case, you know, stuff, but it worked as well as you would expect given the failure mode above.)

That’s OK, though, because I have at my disposal rcd, which usually only eats 100% CPU on my systems for 30 seconds or so at a time, when it’s, uh, well, it’s something really important that it has to do a few times a day. When I start it up, though, it goes into daemon-apeshit-mode immediately, and stays there for quite some time:
  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM    TIME CPU COMMAND 10462 root      25   0 13260  11M 2872  R    92.4  3.0    3:53   0 rcd
“Self”, I say to myself, “self, I wonder what it’s doing with all that CPU time. I bet it’s really exciting and important. Let’s take a look!”
: client; sudo ltrace -p 10462 > /tmp/rcd.ltrace 2>&1 : client; uniq -c < /tmp/rcd.ltrace
  25043 memcpy(NULL, “”, 0)                    = NULL
      1 memcpy(NULL, “”, 0
Are you excited? I’m very excited that it’s sitting there quite literally copying nothing to nowhere. I wonder if Joe will be as excited.
: rpms; ncftp ftp.linux.ncsu.edu

I’m back to 1997!

Posted by shaver at 11:20 AM | Comments (8) | TrackBack
November 30, 2003
with friends like these

A big part of every programmer’s life is debugging. Easily the majority, in my experience, and I like to think that I’m not a lot worse than average at this programming thing. Given that so much time is spent on it, the tools used can have a material impact on the quality of life of a debugging programmer.

On Linux, the debugger of record is gdb, which is often to the practice of debugging as a gasoline aquarium is to fire prevention. I’ve been playing with some C++ software over the weekend, and this has given me occasion to experience the joys of gdb anew:

(gdb) p *this
Segmentation fault

[…time passes, work is repeated, hopes build again…]

(gdb) p _server
Segmentation fault

Maybe 6.0 will be better, but then maybe not:

Specifically, if you set a breakpoint in a constructor or a destructor, gdb will put a breakpoint in one of the versions, but your
program may execute the other version. This makes it impossible to set
breakpoints reliably in constructors or destructors.

I wonder how much MSVC costs around here.

Posted by shaver at 11:36 PM | Comments (3) | TrackBack
October 09, 2003
it's not smuggling if they aren't paying attention

At the best of times, I’m a pretty soft touch for interesting gadgets, and when my good friends start acting as “enablers”, well, there’s not a lot that can be done. So I came back from Boston with a shiny not-quite-new iPod, and now I’m stuffing its abundant music hole with the most reckless of abandon. (2.8 gigs of Tragically Hip bootlegs from the year 2000 alone!)

On the way back, I clearly and righteously marked my toy’s value on the customs form, and was then somewhat surprised when they didn’t ask me to pay any duty; I had exceeded the 48-hour limit by a fair margin, and was three days short of the next allowance up (which would, in fact, cover it). I didn’t think it was my job to tell them their jobs — though I am often assertive about such corrective measures, I am pretty much never thusly inclined when dealing with customs and/or immigration officials, duty-owing or no.

I’m enjoying the iPod (30GB, “refreshed” with full warranty, touch-wheel, dock, middlingly-slim) quite a bit so far, which should not surprise anyone familiar with the concept of “new gadget honeymoon”. Tyla seems to like it too, which is an endorsement of a subtly different kind. If the Linux firewire support doesn’t go completely asshat on me tomorrow when I try to attach it to my desktop at the office, I will consider it an unqualified success.

Posted by shaver at 03:38 AM | Comments (5) | TrackBack
September 06, 2003
a disturbance

There was a little bit of hard-knocks learning on the system that hosts this site today, on the topics of recursion, filename globbing, and permissions. I think it’s all better now, and I think we’re all set in case of a nation-wide apology shortage, but if you notice weird stuff here, or you run a service or something on the box and you notice weird stuff there, drop me a line.

Of course, I’ll be at our landlord’s cottage this weekend, so a fat lot of good that line-dropping will do you.

Posted by shaver at 12:39 AM | Comments (0) | TrackBack