> 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.
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.
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.
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.
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.
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.
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.
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.
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.)
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!
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.
Here's how litl webbook is like a netbook:
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"
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:
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.
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.
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.
Haven't had time to blog in months ...
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.
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.
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.
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):
Nice, factual, 1-chart explanation of the competing tax proposals. (Thanks Luis.)
Barack Obama's policy proposals.
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.
"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.
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.
(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.
Most people know about the price/earnings ratio. If you want to learn one more thing about financial numbers, return on equity could be a good choice.
Return on equity is annual profit divided by net worth. If you have $100 in net worth, and make $10 in annual profit, then you are making 10% ROE. If you think you can make a 15% return elsewhere, you could sell your assets to net $100 in cash, and invest in the 15% return elsewhere.
Depending on the nature of the business, maybe you can add more net worth and make more profit. If you're making $10 on your $100 tied up, maybe you can add another $100 and now make $20. Still 10% ROE, but more money made.
This is supposed to determine what companies do with their profits. If they can reinvest into the business (or at least, some business) at a decent ROE, then they should do so. But if they can't, they should be paying the profits out as dividends their stockholders can invest elsewhere.
Say you propose a project for your company to undertake. The key questions might be the return on equity, and how much equity can be invested. (Making 500% returns on twenty bucks might not be very interesting for a large company.)
Return on equity can be broken down to understand why a business activity is making money. An equation called the DuPont system tries to do this.
The DuPont system is:
ROE =
(Margin - how much of each sale is profit) x
(Asset Turnover - how quickly inventory is sold) x
(Financial Leverage - how much did we borrow)
Different kinds of business make money in different ways, even in the same industry. For example, some few-months-old numbers for Dell and Apple (numbers don't quite add up due to rounding error; numbers are from Morningstar):
Not surprising. Dell makes money by selling a lot of stuff quickly for a low profit, using more borrowed money. Apple makes money by selling more slowly, but for higher profits. Both are workable models, neither one is wrong. Both companies are single-minded about their approach; Dell has focused on increasing turnover rather than increasing margin, and the opposite for Apple.
Leverage is the most dangerous way to make money, because if the margin flips negative the ROE goes negative. Banks make their money on leverage, and they are supposed to be conservative about ensuring the margin stays positive, for example by only making sound loans to people who can pay them back.
The worst kind of business is high leverage with a low, but unstable, margin. Example (other than subprime lending): airlines.
Airlines are always about to go bankrupt. The margin depends on ticket prices (which they can't raise very much without losing sales), and fuel costs (which they don't control and which bounce around wildly). They can't control the margin, and on top of that the margin is low so requires high leverage to make the ROE worthwhile.
Perhaps this explains why airlines are awful to customers. They can't afford to spend any money.
Here's what a business activity should not be about: growing revenue. Often it's possible to grow revenue by reinvesting in a business (say, hiring more salespeople, building more manufacturing capacity, running ads) ... but the ROE may be too low. If customers don't really want the increased sales enough to pay for them, then margins are low or even negative. At that point it would be better to invest in an index fund, or a savings account, rather than in the business. It doesn't make sense to spend a bunch of money selling stuff people don't want.
ROE determines what sort of price/earnings ratio is acceptable, because (in theory) the earnings will be reinvested at the ROE. If an investment pays 10% per year reinvested at 10%, that is worth a lot more than 10% per year reinvested at 2%. So the stock price should be higher relative to earnings.
I find it helpful to flip price/earnings over (earnings yield). It gives me much more pause to invest in something yielding 2% than something with a P/E of 50. Higher P/E almost sounds good - it's higher, right? Maybe this explains the tech bubble.
Both ROE and P/E require all kinds of adjustments and normalizations to remove accounting artifacts before they mean all that much. That's one reason it's futile trying to buy stocks if you aren't a qualified analyst (or relying on one).
As concepts, though, these ratios should help you decide what makes sense for the businesses you're involved with as an employee or owner. Is your company more focused on turnover or on margin, for example? Is your new project proposal profitable enough - would you personally invest in it instead of a mutual fund, if it were your money?