Disclaimer: I've never followed XCB development, this may have all been discussed already, but I hope this post is at least helpful as a data point illustrating what I understood and didn't understand.

Julien Danjou was disappointed recently because after porting dbus-launch to XCB, we had a bit of a "what's the point?" reaction to the patch. Why move "#ifdef XCB" up into apps, when libX11 is already a compat layer that uses XCB if available?

However, XCB remains a useful idea. For the litl OS shell, we've discovered that we really need certain X requests to be async. I ended up digging into the XCB code to find an obscure bug. Since I'd just read a bunch of XCB code, I figured I'd try to expand on the API docs. Hopefully someone can fix up my docs efforts and land them upstream. (If you happen to notice bugs in my docs patch, please comment on the bug.)

Better docs ought to help people know when and how to use XCB. But the library could also benefit from two larger changes inspired by the higher-level desktop toolkits.

1. Better support a main loop, in addition to threads.

Heck, even server-side developers are piling on this bandwagon lately. XCB goes to a lot of trouble to support multithreaded operation. Unfortunately, multiple threads messing with UI code is highly problematic for most actual Linux toolkits and apps. (More conceptually: because X replies are always returned in request order, and the X server is single-threaded, everything is serialized anyhow...)

I filed a bug with my theory on what XCB needs for better main loop support. Please, comment on the bug with corrections and improvements.

I'd like to be able to queue a reply handler as a main loop callback, something that's difficult with XCB as it stands, unless I'm missing something.

2. Export the protocol introspection data (and use it to "dynamicize" protocol bindings)

XCB is in the pre-gobject-introspection school of binding implementation, i.e. libraries full of autogenerated stubs. (Not saying gobject-introspection invented dynamic stubs; COM and CORBA have it, as does Qt, doubtless many other things before that. But gobject-introspection is the GNOME version.)

I filed another bug proposing that XCB could export a binary "typelib" for the protocol. This could remove all request-specific code from non-C language bindings. It could make the C language bindings smaller, too. And it makes it easy to write debugging tools and code.

If the C bindings were dynamic, they could export two other flavors of each request without adding bloat: a "fire and forget" flavor that ignores both errors and replies; and a blocking, synchronous flavor (matching the convenience of libX11). These two flavors would be nice to have, without them XCB code can be more verbose than it ought to be. (It's a poor advertisement for XCB when the patch to go from libX11 to XCB adds extra lines of code, which happens most of the time when you make a request with a reply - at least two lines in xcb, vs. one in Xlib.)

A bonus suggestion!

An easy X protocol debug hook would be fantastic. xtrace doesn't provide easy customization for a particular debugging problem or particular application. I'm thinking something like:

void xcb_set_trace(xcb_connection_t *c,
                   xcb_trace_callback_t out_callback,
                   void *out_closure,
                   xcb_trace_callback_t in_callback,
                   void *in_closure);

Where I'm not sure yet if xcb_trace_callback_t should just take raw bytes to be parsed by the app, or should be passed something higher-level including sequence numbers and opcodes. A problem with higher-level would be the need to parse the requests Xlib pushes through xcb_writev() inside XCB. A potential middle road would provide raw bytes to the trace callbacks, but export a simple X protocol parser API that apps could use for tracing.

A trace hook wouldn't be as useful without exporting the protocol description "typelib" so apps and tools can make sense out of what they're seeing.

Adding XCB utility

At the moment, for a single-threaded application XCB only helps you vs. Xlib in a narrow set of situations where you are willing to block on a reply eventually, but not right now. This is handy to "batch" requests as in the tutorial examples (search for useXCBProperly).

But XCB could offer much more, such as main loop async callbacks, dynamic language bindings, and debug/trace support. These are simple features to add to XCB, that would have been hard to add to the old libX11 codebase.

Just a bit more "what's in it for me?" would be helpful when it comes to convincing apps and toolkits to port over to XCB.

One more thing!

While I'm posting: it seems to be hard (impossible?) to use libxcb-glx because libGL doesn't export a way to get or set the context tag. Not sure where to file this bug or if I'm just missing something.

> Read More... | Digg This!

> Read More... | Digg This!

Nat Friedman has interesting results up for his informal survey on computer frustration, noting that "About a third of these issues could be addressed by webbook efforts like ChromeOS and litl, although the webbook model will probably raise new issues as well."

Seems like a good time to discuss how we designed the litl webbook to reduce computer frustration.

Design with a computer-frustrated audience in mind

We designed litl OS with Cooper, Pentagram, and our own design team. Cooper contributed a set of personas, adding to our own thinking about who would love the litl. We focus on busy families at home. While we have big dreams for how litl OS can evolve, for now we didn't think about work computing, ignoring the needs of business travelers and IT guys.

Windows will ask hundreds of questions busy families don't care about understanding. It's not that they can't understand, but they do not care. (The most famous example might be Vista's overzealous need to "Allow or Deny?"). We can say definitively that our audience doesn't care about this stuff, and so we don't ask it. Period.

As geeks, who have been spent our entire adult lives using and administering PCs, we tend to think the entire world is like us... the more the better... we want total control.  Our research (and our own families) have shown that there's a huge portion of the world, such as busy moms, who only care about results. They don't care about tech specs, and they don't care about tweaking what Tufte calls "computer administrative debris."

As software developers, we don't realize how much worthless debris we put in front of people.  Stuff they don't care about or don't need to know. At litl, we're trying to take a different approach.

Make the OS automatic

If your favorite web app or web site fixes a bug, it isn't nagging you about whether you want the fix. You simply get the fix. We approached litl OS in the same way. litl OS is smart about avoiding updates while you're using the webbook, and quietly updates itself while you sleep.

Hide implementation detail - manage it for you

File management is one of the more complex features of traditional operating systems, and litl OS avoids it entirely. Web apps just store their stuff, they don't ask you where to store it. We continue the entire OS in that spirit.

Sandboxed Sites and Channels

Applications on the litl don't have free run of the operating system. We have two kinds of "app"; web apps running in our browser, and channels. (Channels are a special kind of app with three states, one for lean-forward/laptop, one for lean-back/easel, and one widget-like state in card view.) Channels are run by a custom flash player in their own process.

This gives us a number of tools to control malware (since we don't have to distinguish it from "normal" unsandboxed apps), and it throws out all kinds of complexity associated with installing and updating traditional application software.

Sandboxing eliminates a whole class of "system integration" issues where applications interfere with one another or with the OS. On the litl, web pages and channels can't (and need not) install their own annoying updater software. They can't add tray icons to your screen. They can't break other apps in unforeseen ways.

Hardware/Software Integration

Building for a single hardware platform throws out whole domains of complexity. There's no mess of interface on the litl related to hardware drivers; we know about our hardware already. We know which buttons are on the keyboard (and incidentally, a bunch of useless ones are not). We know the screen resolution.

This means no setup or configuration to start using the litl. It means our help and instructions can be precise - instead of "look for the key that says..." we can say "press the big blue key in the lower left." It means we can ship the litl preconfigured with information entered during the ordering process. It means any number of OS features "just work" instead of requiring tuning to the particular hardware the customer has.

Eliminate the hard drive

The hard drive is the number one point of failure in PCs, and when it breaks, it's a disaster - you lose all your stuff. Best practice is to use the hard drive only as a cache, keeping a backup copy of everything on some web service. litl does this by default, going further to automatically manage the cache so it only has what you're actively using. No hard drive failures; no data loss; no setting up or managing backups.

A new issue: web service integration

The webbook model isn't all positive complexity-wise (yet) - as Nat says, it may raise new issues. Here's one: a litl OS design principle is to use any and all existing web services and apps, rather than reinventing the wheel. We decided to use web mail rather than create our own litl mail app, we decided to use Flickr and Shutterfly rather than invent our own photo storage and sharing site, and so forth. We see our goal as improving the web, and helping people use the web, rather than replacing the web with a "walled garden" of litl-branded services.

There's no question that a "walled garden" of services we controlled completely would be simpler and easier to use. But we don't think our customers would be happy as hothouse flowers. We want to be the best OS for using the whole Internet, rather than a limited appliance.

A Challenge: Internet and WiFi setup

Internet and WiFi setup are tough to address, because problems on the access point side are outside litl's control. Still, on the litl itself, wifi configuration couldn't be simpler - we start with a big list of access points, instead of a tiny little tray icon. People need to recognize their network name and know their password. If they have those two things, we automate everything else.

Personal anecdote: I recently helped my sister fix her wifi; there were two problems, and both were caused by Windows complexity.

First, Dell had installed some garbage "wifi manager" software that interfered with Apple's AirPort software. On the litl, we don't ship OEM crapware.

Second, when you add a network, Windows opens this absurd, verbose dialog that makes no sense; she'd clicked the wrong answer. litl OS does not ask this sort of question, by design. If we don't think our customers care about a question, we don't ask it. (This has nothing to do with the webbook model per se; but it does have to do with our well-defined target audience. We know our customers don't care about this question.)

Only the beginning

We've come a long way with litl OS, but there's a lot more we could do. Nat's survey mentions printing; we could automatically discover printers with no driver installation. He mentions performance; we could manage CPU usage of sandboxed sites and channels to keep the "too much stuff" problem (too many open sites) from degrading performance. We could much more extensively lock down the OS using SELinux-style technology, to further restrain malware. There are so many possibilities because the OS is truly managed on behalf of our customers, not managed by our customers when they have better things to do.

To be sure we get this right, we're planning to rotate the litl development team through customer support, giving every software developer firsthand knowledge of our customers.

We would love to hear your ideas on how to further reduce computer frustration - let us know!

> Read More... | Digg This!

We've had lots of great comments on the litl webbook (see here and here for samples). Some discussion about whether a "webbook" is really different from a "netbook." Here's why litl webbook is not a netbook.

• litl OS is completely different from Windows 7. You can't even run Windows or Linux very well on the litl because our custom hardware is missing legacy keys and ports. litl OS is entirely managed, all state stored online, with web apps and channels only.
• No hard drive. And you don't need one. There's no way in litl OS to even see how much disk space you have, because in litl OS disk space gets used like a web browser cache. You never manually create or delete anything. The hard drive size affects how often we'll get a cache hit. Otherwise, who cares. Web apps don't store files on the hard drive.
• Comes with online storage and services. litl OS syncs its state to the server, supports sharing any card (web page or channel) to anyone in your friends network, and has a friends network integrated into the OS. Backup and sharing are built-in, trivial, and automatic. There's no subscription fee.
• litl webbook is a fabulous photo frame. It has a nicer screen and nicer software than this $650 frame for example. Family and friends can share new slideshows directly to your litl webbook, which will show all your own photos and those shared with you in one big slideshow. (Or add channels with just one album, if you like.) Deep integration with photo services you already use means you don't have to do anything special to see photos on the litl. Most photo frames end up in the closet because loading new photos is a manual process. With the litl webbook, your family members post new photos and they appear as a channel on your litl. No work to do.
• litl's build quality and design blow away netbooks. Most netbooks are "cranked out," with the engineering done in a few months with an eye to minimal cost. litl's engineering was highly refined over time, with an eye to quality, ease-of-use, and aesthetics.
• Screen size and quality. Only one or two netbooks have a screen as large as the litl webbook's, and none have a screen with the same brightness or viewing angle. The litl's screen quality enables "lean back" mode with photos and channels.
• Mobility within the home. The usual use-case for a netbook is travel. We designed the litl to live at home. That's why it has a larger screen, and displays useful and attractive channels when you leave it sitting around house.
• Hardware/software integration. The software is finely-tuned to the hardware, and the flippable hardware inspires one of litl OS's core features, that it's both "desktop" and "media center" all in one smoothly-integrated UI. The litl "look" spans the beautiful packaging, hardware, and software.
• 100% legacy-free. No caps lock. HDMI, not VGA. etc.
• Amazing guarantee. litl's included warranty is better than the service plans you have to pay extra for when you buy a netbook.

Here's how litl webbook is like a netbook:

• It uses an Atom processor. litl webbook uses Atom because it makes the webbook smaller, lighter, thinner, and quieter; not to mention more efficient, saving some trees.

Here's my question: when you go shopping for a cell phone or set-top box, is your first question which CPU it runs? Would you choose iPhone vs. Blackberry based on which one had the fastest CPU clock? Or would you instead first look at what the device does, and in particular look at the details of the hardware and software experience?

Fast Company says

But litl isn't selling hardware specs; they're selling a stone-cold brilliant design. And to appreciate it, you have to be able to play with the device.

But for now, litl is only being sold online. And therein lies the problem. Without handling it, you'll never appreciate the thoroughness of the design language--the scroll wheel on the laptop, echoed in the scroll wheel of the remote; the perfectly weighted hinge which doubles as a handle and hides the battery; the sturdiness of the case; the brightness of the screen; the way the packaging and branding looks domestic but not quite feminine; or even the fact that when the power pack is plugged in, a tiny, embedded LED illuminates the dot of the '"i" in "litl"

> Read More... | Digg This!

If you're against big government, it's time to be specific. You can see the budget pie chart at Wikipedia. Over the next decades, remember that Social Security and especially Medicare become ever-larger slices of the pie.

As an against-big-government activist, how many of the following will you have the integrity to advocate dropping:

• 21%: Social Security
• 16.6%: Defense
• 13.3%: Medicare
• 11.2%: Unemployment Insurance and Welfare
• 9.0%: Interest Payments
• 7.2%: Medicaid and SCHIP
• 5.0%: War on Terror

Total of the above: 83.3%

Everything else is rounding error in terms of cost, though important in terms of impact (education, highways, court system, national parks, bailouts, etc.)

There are two options here.

Option One: You are in favor of eliminating or deeply cutting several of the Big Items in the list above: Social Security, Defense, Medicare/Medicaid, or Unemployment Insurance.

If you believe we should eliminate Social Security, Medicare, Defense, and other stuff with 60-80%-plus public support then I respect your argument and your integrity, but let's face it, you probably aren't a politician facing re-election, and you're advocating something that's not going to happen soon.

Option Two: You are not against "big government"; you are in favor of "let's trim 10-20% off the government while leaving it pretty big" or something like that.

If you really mean "let's trim 10-20%" can we please stop being so melodramatic? As I've whined before, moving government size, or tax brackets, by a few percent is not the difference between capitalism and socialism.

• Libertarian: government should be 5% of its current size.
• Socialist: government should be 200% of its current size.
• Republicans and Democrats judged by actions not rhetoric: government should be 105% of whatever it just was. Disagreement on where the new 5% goes.

Politicians are obligated to be in favor of cutting taxes while raising spending, because the public in the aggregate is in favor of that impossibility. Ridiculous, right? But if you oppose the vague abstraction of "big government" without bringing up which of the big programs you're wanting to cut, you're part of the problem.

There are only 7 areas accounting for 83.3% of the budget. Should be pretty easy to pick one and encourage cutting it as a concrete path to meaningful government-ectomy. It's time to get specific.

> Read More... | Digg This!

Twitter (and mirroring it to Facebook) seem to be replacing this blog. I like what Valerie Aurora writes on her home page:

For those of you born after 1980, a "homepage" is an ancient form of social presence on the web which has been superceded by more structured social networks like MySpace and Facebook. One of the main problems with a homepage was that it is easy to forget to update it. My current homepage is mostly an archive of the past and a collection of pointers to my current active Internet presence. Hope you enjoyed your history lesson!

Awesome.

Because impending parenthood and working for a startup aren't enough stress for one year, we've decided to relocate. (This has been the plan for several years, but stuff kept coming up. It seemed a bit now-or-never at this point.)

If you've seen the movie Away We Go, we did a trip like that in 2007 and again this year. The movie is about two people exactly our age, traveling around deciding where to live while expecting a kid. (Aside: the main characters in the movie made sense to me, but critics described them as unbelievable personalities. It seems movie critics don't know a lot of extreme introvert couples. Maybe we should get out more.)

Last year I got a lot out of a book called Who's Your City, which is a kind of flip side to The World is Flat. Who's Your City sounds like a "decide where to live" book but in fact it's about economic geography; Richard Florida argues that cities are essential to knowledge work, and that economic growth in recent decades has been due to knowledge work in regional centers (finance in New York, tech in Silicon Valley, sales in Chicago, etc.) ... the geographic clustering allows people to network, jump jobs, launch startups, exchange ideas, and in general get things moving. This book claims the world is becoming less flat, with a widening economic and cultural gap between urban knowledge workers and everyone else. You can understand a lot about people's gut reactions for or against Barack Obama from this one.

Relevance to our move: economically, it's near-insane for software developers in the US to live outside Silicon Valley, with a very short list of second-tier options (Boston, Boulder, RDU, Austin, maybe a couple others). And I love startup-type work environments, groups of smart people, and all that tech industry goodness. Amy's nursing specialty creates a similar situation; it's only found in large hospitals.

Aside from work, though, these places don't match us very well. (Work is not the only factor.)

It turns out that litl's parent company has a (small) office in Asheville, NC, a city on our short list for many years - it's near family, pretty, not too large, not too boring, affordable, lots of outdoor stuff to do. We enjoyed North Carolina when we lived in Chapel Hill.

The downside of Asheville is that it's not a tech industry kind of place. That's the risky (insane?) bit of the move, but I'm hopeful it will work out. Oddly enough, in practice it's almost more convenient to Boston than where we live now ... instead of being two hours from litl's Boston office, I can be five or fifteen minutes from the office in Asheville, complete with a fancy video link to the team in Boston and London. Going into the Boston office two days in a row was already 8 total hours of commuting, flying to Boston for a two-day trip isn't notably worse.

This will continue our North-South ping-pong, for me Georgia, Chicago, Chapel Hill, Boston, Asheville. Amy was there too except for the Georgia part.

Long story not short, we'll be in Asheville in a few weeks, but I'll still be in Boston often for work. And we'll see how it goes.

> Read More... | Digg This!

Haven't had time to blog in months ...

• Have been working on litl during nearly all available hours... it took some time (doesn't it always?) but we have a great team assembled and it's a ton of fun to focus on writing the code rather than hiring, and see the rapid progress a complete team is able to make. (If you want to pile on, we aren't urgently hiring, but we probably will be at some point especially for the right person, so we'd love to see your resume.)
• There is nothing better than getting high-quality work done with a high-quality group of people.
• Clutter is rapidly approaching 1.0 ... spent some time this weekend patching the remaining issue that was driving me crazy, hoping to get it in under the wire. Emmanuele may be owed beers.
• It's gratifying that the new default home screen of Facebook looks a lot like Mugshot.org, a site some of us came up with at Red Hat. We coded Mugshot's personal-lifestream-thingy before Facebook's news feed came out and before FriendFeed came out. Not saying either site copied us, but it's still nice to know at least our idea was good (even though there were lots of reasons we weren't the ones to get anywhere with it).
• It used to be that the cool kids claimed to have listened to R.E.M. before Document (these are cool kids 20 years ago, I guess). I was listening to mutual fund manager John Hussman before he showed up on fivethirtyeight.com and in the Wall Street Journal. Am I a cool kid? Ha.
• New York Times tries to explain why people get distracted by small(er) things like millions in AIG bonuses, while missing large things, like billions to bail out AIG's bondholders. Possible Occam's razor answer: most people don't know what a bond is, but they know what a bonus is.
• Some spammer selling Hewlett-Packard products took over my Twitter account "hp", and now Twitter seems to have deleted it - and allowed someone else to grab the account. I emailed Twitter a while back asking them to fix it but all I got was an autoresponse saying "we've taken two weeks and still haven't gotten back to you, let us know if you still need help." I rarely twittered anything anyway, but ... lame.
• Funniest thing today was a random snark on Ayn Rand that Miguel reposted.
• Why is it reasonable to pretend that socialist or libertarian principles can guide a decision between 35% and 39.6% tax rates? Sure, 5% vs. 80% is an ideological debate. But 35% vs. 39.6% is a pragmatic debate. The vast majority of American voters agree on the main government spending items - social security, medicare, defense - that eat up most of our tax revenues. Controversial spending items are too small to affect the tax rate much. And the vast majority of Americans are opposed to 50-60% tax rates. We're going to stay right about where we are because big tax hikes and big spending cuts are both third rails. Here's some historical perspective; tax rates are much more stable over the last few decades than they have been over the last century.
• Amy discovered Cake Wrecks (scroll past Sunday, they have non-wrecks on Sunday). Awesome.

> Read More... | Digg This!

For GNOME summit attendees we're buying some coffee, dessert, and snacks on Saturday afternoon from a local French restaurant. litl's founder John Chuang plans to drop by as well to meet people and learn.

This isn't a talk or a big announcement (litl will still be in stealth mode post-summit) - the idea is to say thanks to the developers behind GNOME and introduce ourselves.

The litl devel team will be around all weekend, doing some hacking. As you may have guessed we have quite a bit of code written in JavaScript, with a C/C++ core. We've invested a few weeks splitting the JavaScript/gobject-introspection bindings out of our codebase and rebasing to newer gobject-introspection. By Saturday we hope to have it compiling and posted, so we can hack on combining our work with Alex's gscript API among other things. We might also sign up for a technical talk about the bindings if people are interested in learning more.

> Read More... | Digg This!

In an effort to outdo other software developers in nerdiness, I read a blog called Accrued Interest, subtitle "Come for the analysis and research on the U.S. Bond market. Stay for the geeky Star Wars references."

Accrued Interest has a nice explanation of how the credit crisis affects everyone.

Here's another good one from the New York Times.

> Read More... | Digg This!

I've been wondering for a while why nobody contrasts Obama's health care proposal with some of the past Democratic proposals. It's a market-based, incremental proposal, that makes use of existing programs and existing insurance companies.

Today Obama's campaign has a new ad making this point, so I guess I'm on their wavelength. After my What happened to John McCain? post, the next day Obama ripped that off, too, for a negative ad.

Finally fixing health care would make a huge difference for quite a few people I know. It may be the single most consequential thing the government could do.

If you watched the debates, see factcheck.org's coverage. They ding both candidates on multiple claims.

> Read More... | Digg This!

Worst stock plunge in 20 years.

Here's a relevant post from last year, when the stock plunge was much less dramatic.

Lessons for the next bull market (yes there will be one eventually):

• Low interest rates and high liquidity do not mean stock prices will stay up. Those things are indicators of insufficient risk premiums, not indicators of permanent demand for assets.
• If companies have 2x their long-run average profit margins, something unsustainable is going on. Abnormal profits don't last forever in (more or less) free market systems, due to competition and the business cycle. Anytime you read an article that mentions a P/E ratio, without discussing normalized margins, run away in fear. (The inverse goes as we most likely head into recession. P/E ratios will become misleadingly high, while in the bull market they were misleadingly low.)

> Read More... | Digg This!

Nice, factual, 1-chart explanation of the competing tax proposals. (Thanks Luis.)

Barack Obama's policy proposals.

> Read More... | Digg This!

McCain was always the respectable Republican, who opposed tax cuts without spending cuts, did not deny environmental threats, had a reasonable approach to immigration, and was against the scorched-earth Rove-style politics. Somehow he has reversed himself on all of these things while running for president. It's not even clear he still opposes torture (see this vote, for example).

I don't consider flip-flopping in itself to be bad; the famous Keynes quote is, "When the facts change, I change my mind. What do you do, sir?"

But the facts haven't changed, McCain has. Read this interview with Time magazine - cringe-inducing. I just feel bad for him.

McCain 2008 is so unlike McCain 2000, it's very hard to understand what's going on. I'm not willing to write this one off as "politics" because it feels unusual and strange.

On top of McCain's personality-ectomy, since just before the convention, his campaign has kicked into a series of frivolous distractions. The New York Times has an article and an op-ed about it, but if you're a New York Times hater, factcheck.org is excellent and calls both candidates on their inaccuracies. factcheck.org doesn't try to make a subjective judgment about which candidate distorts the most, but read the last couple months of fact checks on each of them and see what you think.

On at least two substantive policy matters, taxes and health care, the candidates are failing to have a real discussion - McCain has been repeating misleading talking points instead of engaging with and debating the actual proposals.

And Sarah Palin - in her first interview, she says this with a straight face:

What insight into Russian actions, particularly in the last couple of weeks, does the proximity of the state give you?

They?re our next-door neighbors. And you can actually see Russia from land here in Alaska. From an island in Alaska.

Come on. She's applying for a serious job.

While a hollywood actor mocking creationism is not going to win over any swing voters, I have to agree with the "Disney movie" part of the sentiment.

To combat this, before announcing Palin's nomination, the McCain campaign seems to have invented a narrative that "they" are attacking her family, attacking her because she's a woman, blah blah. Even though Obama did the opposite and condemned attacking her family, McCain stuck to the talking points. And though it took his campaign a couple weeks, they found this "lipstick on a pig" comment they could use as "evidence" for the talking points they'd already been pushing. Obama responded very well - emphasizing how ridiculous it is to play games given the weight of the substantive issues at stake.

If your attention span is too short to watch Obama's serious responses, Jon Stewart takes apart the pundits on Palin in a more humorous way.

It makes me sad. When McCain won the nomination, though I was not going to vote for him, I was happy that we would have two people running with competence and integrity well above the politician average, and well above most of the others in the primaries. It felt somewhat "can't lose" - the upgrade from Bush would be significant either way. McCain 2008 is still better than Bush (it's not a high bar). But "new McCain" has been very disappointing compared to McCain 2000.

Mike Evans reposted a nice case for Obama from Marc Andreessen. Unfortunately, where the majority of young people and "knowledge workers" see competence, a lot of swing voters seem to see something negative.

There are serious problems facing the United States, especially the US economy, and the economic problems ripple through national security and other issues. Our economic problems have some straightforward answers: simplify the tax code, make it a bit more progressive so we have a solid base of consumers to buy stuff, reduce lost productivity and inflation caused by a broken approach to health care, and - the big one - address the redistribution of wealth and power from the US to other countries created by our oil dependency.

One of the presidential candidates wants to talk about credible solutions to these problems, and one of them wants to talk about distractions.

> Read More... | Digg This!

"If synchronous IO becomes a problem, it can be made asynchronous later." Tempting to imagine that some operations on local files are "fast enough" to implement with synchronous IO. "Premature optimization is the root of all evil," right?

Wishful thinking. Async vs. sync IO is not a performance issue (in fact synchronous IO can be faster). It is a structural or qualitative issue, a design issue. Sync IO is guilty until proven innocent.

My new rule is: any code that will be blocking during a user-interactive main loop must run in a known-short time. The task must be known short, not indefinite-but-often-short.

Local file access could be short, but is not known short. Another common culprit: synchronous D-Bus calls.

I've seen so many rewrites from synchronous to asynchronous IO over the years - it is almost 100% likely that anything blocking the main loop eventually comes to be seen as a bug. There's near-zero chance it's really OK to use those nice, easy-to-program blocking D-Bus calls, or that nice, simple g_file_get_contents(). Even the harmless looking g_file_test() can bite.

These APIs exist only to tempt you. They are the dark path.

(Note: by "asynchronous" I mean "the main loop is not blocking, for example because IO is in its own thread" - I don't mean special AIO system calls.)

Here's the core issue: the UI's main loop needs to wake up at 30-60 frames per second to do animations and repaints, and it should respond to user input with similar speed. It needs to do this consistently (think real-time-like), not "on average" - if there are big outliers, like an occasional quarter-second delay in frame rate, the app will feel sluggish.

"Local" IO can be slower than you think; the firefox fsync problem shows one extreme case (the whole kernel gets bogged down, not just the IO operation), but think about network file shares, or large file sizes, or systems under load. Even mild manifestations of these issues are visible in decreased user responsiveness and animation smoothness.

It's very common for supposedly fast IO operations to end up batched together, creating a long delay at once; for example, calling stat() on everything in a directory, or queuing a bunch of idle handlers that all happen to kick in at once.

Another Firefox example: try uploading a bunch of photos to Flickr in one go. Ouch. The files are local, but ... there are a lot of them and they are big. Pretty sure Firefox uses synchronous IO here.

Enough "this local IO should be fast enough" laziness scattered around an app creates distributed bloat that's hard to pin down and doesn't show up very well in profiles because it depends on external circumstances.

Not only is it hard to find later, synchronous code is hard to fix - it means rewriting.

Bottom line: don't write this code in the first place. Using async APIs is not premature optimization, it's correct design.

> Read More... | Digg This!

Chris mentions JavaScript embedding using SpiderMonkey.

When GNOME first started out, there was much talk of using Guile as an embedded language. The concept was similar to the architecture of Emacs, Firefox, or all the games using Lua (such as World of Warcraft).

I would define an "embedded" language as one that doesn't come with a platform. It's small and easy to glue together with an app written in C or C++. It uses the same platform as the app. If the platform has an introspection capability like XPCOM or GObject-Introspection, then the platform can be exported to the embedded language in an automated way.

At some point, and I was one of the people to blame for this, we changed the focus of the Linux language discussion to grand unified schemes involving component technologies and virtual machines. The result is that too much desktop stuff is still written in C.

A "C/C++ core plus embeddable language" architecture for an application has many pragmatic advantages.

• Higher layers of code such as UI code are so much easier in a dynamic "scripting" language.
• Proven to be practical and scalable for huge apps such as Firefox and World of Warcraft, even with dead-simple languages such as JavaScript and Lua.
• No platform silos. In a GNOME app, the embeddable language uses GIO, GTK+, GStreamer, Clutter, or whatever you are using - it does not have its own http stack and everything else.
• You can choose to write each part of the app in the easiest language; some stuff is easier in C/C++.
• Sandboxable / well-modularized. The interpreter is generally an object that can be destroyed; no heavy language runtime or VM takes over the entire app.
• Embeddable languages don't seem to create a huge jump in memory footprint, for whatever reason, so they are still sensible for "swarm of many processes" environments like GNOME and KDE that multiply any per-process overhead by a significant factor.

(There are advantages to the heavier full-platform languages also, but I'm guessing everyone knows them already so I won't make a list.)

JavaScript is a great choice for an embedded language. I did not realize at first that SpiderMonkey has no dependencies; it is not tied up with the rest of the Mozilla platform (XPCOM, etc.), it's completely standalone. And most programmers understand at least some JavaScript already.

There are some problems right now, for example there's no standard packaging and .pc file for jsapi.h/libmozjs.so, so it's hard to make an app build on multiple distributions unless you suck in an internal copy of the library.

It's necessary to add a couple things to JavaScript before it's truly usable; most notably, some kind of module system. I'm not sure SpiderMonkey itself should have that though - it starts to define a platform and make the language "not embedded". Maybe modules are introduced by higher layers (in fact xulrunner adds a module system if you use the whole xulrunner platform).

I don't mean this as a SpiderMonkey advocacy post, though we're using it successfully at work. Other options are the WebKit JavaScript engine, Guile, Lua, Tcl, etc.

My main point: the "C/C++ core plus embedded scripting" architecture is a very smart way to write an app, and doesn't have some of the real downsides of heavier platforms.

> Read More... | Digg This!