At the post office, I found myself writing a bit of a pastiche of an old classic:

Passport Hours: 10:30-4:30

Nice work hours if you can get 'em

NOTICE: TO SERVE YOU BETTER, PASSPORT SERVICE IS NOW BY APPOINTMENT ONLY

And you can work less, if you try!

1:40 PM:

Applicant has been waiting since around 1:30 PM, occasionally ringing doorbell.

Postal Service Employee (annoyed, poking head around door she is holding mostly closed): When's your appointment?

Applicant: My appointment was at 1:30, Ma'am

Postal Service Employee (even more annoyed): Can't be at this post office. You must be at the wrong post office. I have lunch from 1 to 2.

...

Suddenly, I find myself thinking that privatizing postal service might be a good idea after all. Also, putting the phrase "to serve you better" on a sign or form should be a federal offense, publishable by standing in line at a post office for 10 years.

I will be presenting and giving a tutorial (two separate sessions) about Application-Centric Systems Management at LinuxCon 2009 September 21-23 in Portland, Oregon.

Application-Centric Systems Management: Presentation

Historically, applications have been managed separately from the operating system, which have been managed separately from frameworks. The OS and frameworks have been managed with a one-size-fits-all homogeneous approach, leading to large OS+framework installations that support all relevant applications. Application developers have been expected to develop applications to a platform with minimal version changes, without taking advantage of new features and bug fixes. This wastes time and money. rPath's tools deeply introspect all software components and provide strong version control management of all system image file contents. This allows application-centric system image definition that reduces collateral damage from OS/framework updates while allowing agile application development and deployment.

Application-Centric Systems Management: Tutorial

A practical follow-on to to the Application-Centric Systems Management presentation, this tutorial will guide the participants through the use of several of rPath's tools (particularly Conary, rMake, and rBuild) for application-centric management of heterogeneous systems. This will include packaging source code and binaries, composing them into groups, and managing a sample software lifecycle including application development, QA, and releases. This will be a hands-on tutorial that requires participants to bring working systems with virtualization software already installed. The techniques taught will not be specific to virtualization, but virtualization will be used to facilitate development and testing during the tutorial session.

rPath is now hiring a senior engineer to work on almost everything that rPath does. Conary, rMake, rBuild, rBuilder, and more.

We take testing seriously. We are not wedded to formal "Test Driven Development", but developers here write tests as part of the development process.

We have a vision and a mission: We're bringing distributed source code control ideas to system management.

Several weeks ago, I posted that AT&T billed me fraudulently for services not requested nor provided, "on behalf of a third party". I had been "crammed". (Phone carriers get a reported approximately 30% kickback on third-party charges, so they don't have much incentive to act on behalf of their customers to resolve these complaints.)

As part of the discussions, AT&T said that they had disabled third party billing for my account, that all third-party charges had been credited, and annotated it that no third party billing was authorized.

This month's bill again has identical fraudulent charges applied. I again called AT&T's service line (888 757 6500) to dispute the charges. This time, the service representative was rude, interrupted me often, told me that these charges were my responsibility, told me to call the same scam operators again, and told me that if I refused to pay these fraudulent charges, AT&T would "hold [me] responsible for them" (whatever she meant by that).

When she "transferred me to a supervisor" after arguing with me about it and telling me that a supervisor "would just tell [me] the same thing", either she or the supervisor hung up on me.

When I called back, I was told after a while that a supervisor wouldn't be available for more than twenty minutes and it was company policy that I couldn't use a support line for more than twenty minutes; that they could only take my number and have a supervisor call me back whenever they got around to it. After I complained that this was not an acceptable policy, and pointed out that I was at this point entirely dissatisfied and researching alternatives for my telephone service, I was finally offered an "account specialist".

The account specialist must have been trained to listen, because he let me tell the whole story, including the fact that I am looking at alternatives for phone service, without interrupting me to explain that I was an idiot. Directly in contradiction to the first customer "support" agent I talked to this morning, he said that credits for the second month of cramming had been applied to my account. He even took the time (unlike both the level one agents) to confirm that third party billing was blocked on my account. Also in direct contradiction to what several of the level one agents told me (both on the first of the month and today) he told me that the third party billing block will block all third party charges, period. In direct contradiction to the previous agent, he said there was no twenty-minute support call rule. He also knocked about $14/month off my phone bill. He didn't even try very hard to sell me DSL service... (He did beg for me to rate my experience with him as "extremely satisfied.")

So I guess I won't go through the trouble of changing phone service quite yet. We'll see how it goes.

In all the hullabaloo about ext4 having inconvenient semantics with respect to a crash in close temporal proximity to an application attempting to do an atomic rename to replace file contents, I had wondered whether to propose a single system call that could provide an array of file descriptors to fsync(); I'm not sure if that's "scatter fsync()" or "gather fsync()"... I'm not sure what it would be called; fsyncv() is a bit misleading relative to readv() and writev() but it was the closest I could come up with. And it was beginning to look like we were going to need a way to say "wait for all of these files to be synced" without having to serialize the synchronization of each file individually or starting lots and lots of threads.

Thankfully, Valerie Aurora has explained that common sense is going to win. My thanks to many creative and thoughtful Linux kernel hackers who have spent countless hours pondering the tradeoffs and inventing better solutions.

There may be reasonable use cases for fsyncv(), but fortunately, it looks like someone else gets to think them up, and it shouldn't be required for normal applications. Yay!