Printing from Mac to Linux: the cheat sheet

For the last few years, desktop Linux and Mac OS X alike have used CUPS (Common Unix Printing System) as their native printing subsystem. In an ideal world, this would mean it’s really easy to set them up to talk to each other.

In the world we live in, however, things are not so easy. Configuring CUPS remains a black art, compounded by the absolutely abysmal reporting of errors to the printer UI on both OSes. To have any clue what’s going on you have to seek out and find the log files…

I can understand that on Linux, but really, how did Steve Jobs let this out the door on his precious Macintosh? Heck, Apple even bought the company that developed CUPS a few years back. Stop making our iPods smaller for a couple minutes and fix your printing error messages! ;)

The situation:

I have a relatively straightforward setup: an Ubuntu Linux desktop PC (stormcloud.local) with a well-supported USB printer hooked up, and a Mac laptop (nimbus.local) which roams the world. When at home, it’s nice to be able to print directly from the Mac rather than print to PDF, copy the file, and then print.

The cheat sheet:

First the basics — make sure printer sharing is enabled on Linux; this much you should be able to do through the regular GUI:

Now the voodoo! Add to /etc/cups/cupsd.conf on Linux:

    # Allow remote access
    ServerAlias *
    Port 631

And restart cupsd:

    sudo /etc/init.d/cupsd restart

Now, you can add the printer on the Mac; be sure to fill everything out!

Several gotchas I discovered:

Listening isn’t enough

Very early in my journey I made sure that the Linux box’s cupsd.conf was set to listen on the network as well as to itself:

    BAD: Listen localhost:631
    GOOD: Port 631

But when I’d try to hit the CUPS web administration pages I’d just get a “400 Bad Request”. After some experimentation, I found that it actually responds just fine… as long as in the HTTP headers I call it “localhost” instead of by its proper local network name.

To get it working (so eg http://stormcloud.local:631/ would actually pull something up!) I had to add this to cupsd.conf:

    GOOD: ServerAlias *

No, setting the name I wanted in ServerName mysteriously wasn’t enough.

Pick a queue, any queue

The Mac’s IPP printer setup dialog says you can leave the “Queue” field “blank for default queue”. This is a lie! Despite having only one printer available, I could only get printing working if I listed the queue explicitly.

To add insult to injury, you need to include the “printers/” prefix. This is easiest if you find the printer on the web interface and copy-paste the path from the URL…

Now I can print my dang Fandango tickets, which I’m pretty happy about!


I’ve been using the native driver for the printer on the Mac side. It should also work to just leave it at Generic PostScript as long as the Linux box has a driver, but I feel safer with it there. ;)

Introduction to OStatus: Atom-based federated messaging

I’ve written up the little introduction to StatusNet’s new inter-site federation protocol; for now you can also find this article on the StatusNet wiki. I’ll follow up in the next couple days with demos of the subscription UI and subscribing to Google Buzz feeds as native OStatus data sources. — brion

What is OStatus?

You’re about to learn what OStatus is and how it’s going to make communications between StatusNet sites work better!

Some of you may remember the bad old days when you couldn’t send e-mail between services like AOL and CompuServe. StatusNet/Laconica sites have used a custom protocol OMB to set up subscriptions between sites, but OMB requires special support to be used with non-StatusNet services and is hard to extend.

By building on top of shared technologies already in use and being rolled out, we can go beyond that… our new effort, with better compatibility between sites, is named OStatus.

The basics

If we step back a bit, we find that Atom and RSS feeds are already a lingua franca between sites. Virtually every service provides such feeds, giving a way for other tools and services to read someone’s outgoing posts.

File:Basic-feed.pngAt its simplest, a feed is a list of recent posts with some author attribution.

But the fun of social networks is in real-time interaction — if your updates don’t get sent to your friends right away, it’s just not the same.

Luckily, that exact problem has been solved recently, with PubSubHubbub (PuSH). In the PuSH system, a site can subscribe to updates for a feed from a hub server associated with that feed. Whenever a new post is created, the publishing site pings the hub, and the hub sends out just the new posts to all the subscribers.

OStatus is built on that simple base: each participating site produces Atom feeds of updates and uses PuSH subscriptions to send relevant updates to other sites:


Alice posts a message on; a fragment of her Atom feed is PuSHed out to the other StatusNet sites that have users following her posts. Each of those sites is responsible for routing the message to individual subscribers.

The real beauty of it is that at this point we already have something useful, without anything StatusNet-specific. In fact you can already subscribe to someone’s public Google Buzz feed as an OStatus remote user, and they haven’t done anything special for us!

The good stuff

PuSH is a low-level piece of the puzzle; it’s just a way for services to send updates to each other. For a fully interactive social network, you need that human touch… you want to know who’s subscribing to you, which of your posts they like, and you want to get their replies to you.

For this we’re making use of more extensions that build on top of Atom feeds: Activity Streams, Portable Contacts, and Salmon.

Activity Streams extends Atom feeds to describe social “activities” more specifically than just “ok here’s a post”. Entries are marked with a verb (post, follow, favorite, etc) and more detail on who or what’s being acted on. We’ve extended this further using elements from Portable Contacts to provide profile information:

Extended author information beyond what Atom’s native <author> element provides.

Salmon was created as a way for blog aggregators to send comments back to the original blog server, “like salmon swimming upstream”. We’re using this channel to send replies as well as other user-to-user events:

File:Salmon-delivery.pngBob replies to Alice from his home site; since she’s not subscribed to him, the reply is sent back to as a Salmon ping.

When your friend on Example.Net subscribes to your account, Example.Net sends an Atom entry with an Activity Streams “follow” verb to your Salmon reply channel on This lets know who subscribed to you, so their profile gets added to your subscribers list and you get a notification that they’re following you.

If your Example.Net buddy gets social network overload and decides to unsubscribe from you, another notification comes through about the unsubscribe, and we can drop them from the list.

Other events can be sent over this channel as well, such as when your friends on other services mark your posts as a favorite.


One of the most annoying limitations with OMB 0.1 was that there’s no support for joining a group on another service. You might have noticed that groups have Atom feeds of posts just like users do… if you were wondering if that means groups could be run over OStatus too, you’re correct!

As a user on you can join a group on Example.Net without setting up an Example.Net account. Group posts from Example.Net will appear right in your inbox on just like any local group, and you can even post back to it.

Why OStatus will rock your world

Hey everybody!

Things may have looked pretty quiet the last couple weeks, but here at SNI we’ve actually been rushing to get some really awesome things ready for you all…

In addition to finalizing StatusNet 0.9 with scalability and bug fixes to make it release-ready, we’ve been implementing our new federation protocol OStatus, successor to our older OMB 0.1.

I know the scattered notes we’ve got up on the wiki right now are a little confusing, so over the next few days I’m going to start consolidating those into a clearer picture what OStatus is and how it’ll let StatusNet sites connect better to each other and to other systems.

In the meantime, active work on OStatus is currently proceeding in the ‘testing’ branch in our gitorious mainline repository…

Stay tuned!

— brion vibber (brion @
Software Architect
StatusNet, Inc
San Francisco