June 2006

Self-Reliance: The American Way

Our society puts a lot of emphasis on self reliance. From the
American Dream of pulling yourself up by your bootstraps into a
successful life with a family, a white picket fence and 2.5 children
to our government’s tendancy to unilateral action, we are a people of
individualists.

On the other hand, we are a generous people, too. Charity is a virtue
we highly prize—you should not only get yourself a successful life,
you should be successful enough to be able to give lots
away
. (No, even more
than
that
.)

On a micro scale, I’ve been noticing both these trends: my reluctance
to ask for help while I’m hurt, and other people’s insistance on
assisting me. For example, yesterday I went to buy some tea from the
store here. I’d asked someone to go with me, since it’s a long way to
carry a hot cup on crutches, which essentially take both my hands, but
she got tied up in a meeting so I went alone. When I was there, the
clerk insisted that the person behind me in line carry my drink back
to my desk for me.

This could be dismissed as everyone else being reasonable and helping
me out, and me being unreasonable. I’m not going to totally disagree
with that assessment, either. But I also notice the looks that others
give me when someone’s carrying something for me, or when I stop to
rest because I am too out of shape to keep going at a reasonable
walking pace for more than a couple hundred feet. There is respect
accorded to my assistant, but also pity for them—that I am so weak
as to need assistance, so they had to step up. There is pity for
me, but no respect. When they look at me, I feel like behind the pity is an irritation that
they don’t dare express—that I am am failing to do what I should,
and therefore not pulling my weight in the
larger society (whether that’s society-at-large, a company, a team,
whatever).

I don’t think I feel this way when I see others injured—I mostly
wish there was something I could do—but I can draw a correllary to
the dark thoughts I sometimes have as I pass the beggars along the
roadside. I wonder sometimes why they don’t go get a job, so they
wouldn’t have to beg—so they could do work that would let them
respect themselves and be respected by the community. I wonder if
this is the same dark heart which leads to the feeling I get from
others—whether they mean to give it or not—and to, on a larger
scale, the genocides we see when a large group decides that some other
group is inferior.

katallen

Comments (0)

Permalink

AT&T Privacy

href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9001449&pageNumber=1">
This opinion piece makes some good points about AT&T’s href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9001350">no-privacy
policy. For now, it’s just for their "Internet customers", but a
company willing to do sell their customers’ data for fun and profit
(oh, yeah, and Fighting Terrorists! Right! This is all about Fighting
Terrorists. And profit.) is unlikely to ignore those millions of
phone customers. We shall see.

Thanks to Brian, who pointed out that Cingular bought AT&T Wireless,
which wasn’t the same company as AT&T anyway, so I can still consider
a Treo

katallen

Comments (0)

Permalink

Jim Baen has passed away

Read David Drake’s obituary, requested just a few weeks before his
death. Baen was responsible for publishing and promoting Bujold,
Weber, Flint, Lackey, Laumer, Ringo, and many others. He established
a signature style: It’s a common joke around the MITSFS that you
can tell a Baen book from across the room: there’ll be an author’s
name in big bold type, a scantily clad woman with a really big gun, a
dragon, and an exploding spaceship. He’s published some misses (Rats,
Bats, and Vats comes to mind), but in general the contents between
that distinctive cover will be adventure stories to make Heinlein
proud. Baen Books are often pigeonholed as right-wing military SF by
those who see only Ringo and Weber—and those only on the surface. A
deeper look shows that maybe Ringo and Weber are more nuanced than
their characters would claim, and Baen was busy publishing books by
Socialist labor organizer Eric Flint and "military fiction" like the
later Vorkosigan books.

Together with his friend and regular author Eric Flint, Baen began the
DRM-free Webscriptions project, including the Baen Free Library.
These have been of tremendous value to me, providing a surplus of
reading material while traveling, all easily packed into my Pilot.
They demonstrated that freely distributed copies of back-list novels
can greatly increase the sales of new books, as well as raising
awareness (and sales) of the long tail of the back-list. Moreover,
they’ve demonstrated that plain-text, DRM-free media are a salable,
profitable commodity in their own right. According to Wikipedia’s
article on Jim Baen, Baen’s sales of web sales of
free/libre media were a larger market than Canada.

From Drake’s obituary:

I could not get so crazy and depressed that I didn't trust Jim Baen to
stand by me if I needed him. I don't know a better statement than that
to sum up what was important about Jim, as a man and as a friend.

I never met Jim Baen, but I’m glad for what he did for fandom, for
books, and for the world.

bts

Comments (0)

Permalink

New Teeth for Me!

If href="http://www.scienceblog.com/cms/ultrasound-may-help-regrow-teeth-10895.html">This
can be adapted to stimulate new teeth to grow in people who have teeth
(but ones, like mine, full of nasty silver and mercury), I could someday
have a mouth not full of metal! Of course, it would be full of
ultrasound transmitters for a while first…

katallen

Comments (0)

Permalink

Should Homosexual Christians be excluded from church?

Bet you thought I was going to talk about the Episcopal/Anglican communion, but this has been on my to-write-about list for longer than that. The Episcopals are not the only denomination tearing themselves apart over homosexual Christians—the United Methodist Church is deeply divided, too: Page 6 of this PDF gives a summary of the current situation, where a pastor has denied a transfer of membership into his congregation for a person he believes to be homosexual.

As I dug deeper, however, I found that the division (and the discussion) is pretty historically active: A History

A High (or low)-light: On MAY-8, a resolution was rejected 705 to 210 that would have required a loyalty oath of any minister assigned to a congregation: “I do not believe that homosexuality is God’s perfect will for any person. I will not practice it. I will not promote it. I will not allow its promotion to
be encouraged under my authority.”

Wow, that’s a strong statement. And 210 of the UMC Bishops thought it was a good idea. I am afraid for the Church. I am glad that both my current local church (St Paul Lutheran)and the church I grew up in (AUMC, the one whose newsletter is linked above) have active, independant bishops who are not willing to see anyone excluded from the life of the church.

katallen

Comments (0)

Permalink

Gopher 2.0, Gopher Services, and Hole-Oriented Architectures

Much has been written about Web 2.0. It’s nice to see such a protocol
being revitalized—the wisdom of the Web’s simple elegance
recognized. But much of the WS-* furor seems to have missed the point
of Tim Berners-Lee’s beautiful GET, POST, PUT and embedded
links. When I see serious documents referring to a processor as a
provider of services—and honestly appearing to believe that clock
ticks come individually wrapped in XML—I worry. Certainly, many of
these people seem to believe that XML parsers are small” and should
be ubiquitous. In their haste to adapt pre-web systems and ways of
working to the new buzzwords, they neglect the management and overhead
costs of all these layers of serialization and redirection.

I’ve been pleased to see Tim Bray and others reminding us
all that WS- has little to do with what makes the Web great. But
it’s not enough. Some people are proceeding to build reasonable Web
Services and Service-Oriented Architectures… but in general, they’re
not doing it with the WS-
standards. They’re doing it with simple
HTTP and XHTML, often with REST-based systems. SOAP is nowhere in
sight.

Therefore, I call for advancement by means of a return to still
simpler, more basic good than the Web: Gopher Services. This
provides a much more natural, flexible means for representing
traditional client-server applications in a SOA world.
Gopher, for the young’ns in the audience, was a precursor to
the web. A given site would provide a "gopher hole." Each node in a
hole contains either an ordered list of links or a flat file. Some
links go to nodes in other gopher holes. Like the web, links obscure
the complicated protocol-level description of the link with a
human-readable label. Unlike the web, there’s no place for readable
URLs: humans only get the painted-on link names. Common practice was
to use null or short-cycle links to provide structure and annotations
within the lists. Go look at Quux for an example of how this
works.

Because most links are local, links are separated from content,
imperative links are clearly called out, and a client tends to
interact with its "home gopher hole," this is a far more appropriate
model for bringing Service Oriented Architectures to classical
enterprise computing. Rather than jumping straight to a zillion
tiny separate services, these organizations want a gradual shift.
Hole-Oriented Architectures provides that middle ground. A hole
provides services, but centralizes them. Client-server interactions
fit in well. REST is out of the question, and you don’t have to
pervert the Web to establish your client-server overlay network. You
can just do C-S directly.

To achieve this renaissance, we need to revamp and improve Gopher. We
need to do it Gopher what Ajax and Flash do to the Web, and finish
what TurboGopher VR started back in the early 90s.

bts

Comments (0)

Permalink

Ask a Ninja

Ask a Ninja is the funniest thing I’ve ever seen today. It had
me falling out of my seat on the plane today, earning funny looks from
the flight attendants.

bts

Comments (0)

Permalink

ISO 17799 electronics-oriented?

I just heard an intelligent, IA-focused gentleman discuss his team’s
new information policy framework. It’s neat stuff: a meta-policy for
writing information assurance policies, focused on risk assessments,
continuous measurements feeding back into policy generation, and a
format-agnostic approach. That is, it encourages policies to be
written for certain sorts of information content, not for specific
technologies or storage media.

For example, policies at many organizations are written for Laptop
Drives, Shared Storage, Web Servers, USB Media, Paper Storage, Voice
Mail, etc. These folks advocate writing policy around the content
instead, so regulation of HR/Personnel information is written in one
place, covering it whether it’s stored in voice mail, a filing
cabinet, or an iPod.

That seems like a neat idea. There are problems, of course, but in a
lot of ways it describes why I like functional programming better than
object-oriented programming
: it’s easier to extend on one axis,
harder on another. So I asked the obvious question: how does this
compare to ISO 17799? Ideally, I’d have been pointed to a document
comparing this to a number of other frameworks, including ISO 17799.

They have no such document. Instead, I got told that ISO 17799 is
boring and uninteresting, since it focuses too much on electronic
issues. These folks claimed that, for example, it required regulation
of electronic documents separately from paper documents. Now, I
haven’t looked at this since it was British Standard 7799—and my
notes from those days got left behind under NDA. But I sure don’t
remember it being structured that way. Anyone who works with
CISSP/17799 stuff on a regular basis, am I mis-remembering? Did this
guy’s quick read of ISO 17799 confuse him?

bts

Comments (0)

Permalink

Work and Injuries

I have had a couple different chances, in the last year, to evaluate
how my workplace deals with injuries. They make a big deal about
being a great place to work for all people—disabled, gay, ethnic,
female, young, whatever. We have support groups! I think the support
groups are weird, but it’s probably good that we have them.

But, like so many initiatives from On High, it seems like the
bureaucracy isn’t set up to really help people. There’s a pile of
paperwork if you get hurt on the job in a sudden way, like a fall, and
a bureaucratic slalom course to address your issues if you get hurt in
a more subtle way, like RSI/carpal tunnel. Interestingly, the sudden
injury, though in reality less severe, is the one which got the most
attention and care—my manager is apparently really concerned. (I was
hurt at another site, so I have only secondhand information about why
he’s concerned. Rumor says it’s fear of paperwork, but I suspect,
knowing him, he probably is also concerned about my health.) It took
much more effort to get people to care when I needed a keyboard,
keyboard tray, etc.

I wonder what makes an at-work accident more important than an at-work
longterm injury? Maybe it’s just that a sprained ankle is easier to
diagnose and treat than RSI?

katallen

Comments (0)

Permalink

Why do I write functional programs?

Most programmers these days write in object-oriented programming
languages, such as Java or Python. This category also includes much
Perl 5, C++, and Objective-C code. It even includes much Javascript,
which work on the Document Object Model. Such code is organized as a
collection of (classes of) objects. You get a new object by demanding
a new, blank element of some class, or by demanding that some other
object be cloned. So why do I write functional programs, not
object-oriented programs? Because these are easy and hard to extend
in different ways.

With object-oriented programs, it’s easy to extend them by adding a
new class of object. And it’s easy to add a function to one
class… though you then have to consider all its children. It’s hard
to add a new feature in a broad way, like serialization or access
control: you have to change each of your class definitions, likely
every file in your program. So nouns are easy, but new verbs are hard.

With functional programs, it’s hard to add a new sort of noun to the
world, but easy to add a new sort of verb. Since I tend to program in
Unix-like environments, this is nice: I know generally what sorts of
noun I’ll be dealing with. I write programs to add new verbs to my
vocabulary.

bts

Comments (0)

Permalink