Older blog entries for bwh (starting at number 31)

My Mom is an RN, and her job is to phone a set of patients with a certain chronic illness regularly to get their weight measurements. For this particular illness, sudden weight gain or loss can indicate a pending emergency, and that they should get to the hospital immediately.

Granny Linux is a neat idea from the standpoint of making the computer easy to use for people with limited technical skill, but the idea becomes really compelling when you think about tapping into its potential for medical care.

In my original blog entry I mentioned that my Mom had problems with a website; this was a site for her to record some medical information. Her doctor had asked her to keep track of it and bring in a report at her next visit. Unfortunately, the web application allowed entering the data easily enough, but when it came time to print, that's where we ran into trouble.

Needless to say, the fact that the computer got infected in the process was a minor nuisance compared with not being able to access the data.

Certainly, Linux would be beneficial at preventing the infection, popups, and so forth. However, the root problem of being able to track this medical data would be the same regardless of which OS she was using. The designer of the web app supports IE only, not Firefox (we even contacted him, and he reiterated that he would only support IE).

Now, Mom is pretty good with computers and just set up a spreadsheet. She knows how to use Excel quite well, and this gives her ultimate control over her data. But I imagine there are lots of people who couldn't do that, who would be cornered between IE's bugginess, the lack of support for Mozilla/Firefox by web app developers, and the cost and hassle of getting commercialware. For them, a pad of graph paper and a pen would be the most logical solution. :-/

This seems extremely lame to me. Computers ought to be good at helping people with stuff like this.

I think Granny Linux could do much, much better at this.

By and large, most of these applications are rather simple. Usually they're just logs of your daily exercise, meals, weight, temperature, blood glucose, or whatever. They need to let you type the info in each day, and then print out a summary on a weekly or monthly basis. Or maybe a meal or exercise planner, or perhaps tutorials or presentations about some aspect of your medical situation.

Inclusion of a suite of such apps in Granny Linux would be a no-brainer. After visiting the doctor, Granny could phone John, talk to him about her diabetes or heart condition or whatever (Granny always goes on about her health, even aside from the computer), and that the doctor told her all these things she has to track, and could the computer help her do this? John takes a look and finds that, indeed, Granny Linux can help with tracking blood glucose levels (actually it has the choice of three apps for various levels of sophistication, but he knows Granny will want the simplest one.) He asks if she'd like him to set it up, she says yes, and with two clicks he's installed it. Right there on the phone he walks her through use of it.

It occurs to me that the value could reach even further. Earlier I mentioned about how with some illnesses, abnormal measurements can indicate a problem. Imagine if the Granny Linux medical applications were able to detect these abnormalities and flag them, letting Granny, John, and/or her doctor know about the pending issue immediately. In my earlier post I mentioned about a toolbar applet that would blink on John's desktops if there was an error; imagine tying this in with Granny's medical tracking app, so that if her weight numbers are showing dangerous indication of fluid retention or whatever, it would flag John and he could take action. Of course, there's some privacy considerations here, but I guess John and Granny would balance that against the value of keeping her healthy.

Another thought is that there are TONS of organizations that are trying to find ways to help their people manage their health. Insurance companies, hospitals, state and federal health care non-profits, and so on. I would imagine these groups would be quite interested in something like this, that could give their members really good health management software for free, without incurring them with all the troubles that come with Windows. I could easily imagine them wanting to participate once the concept was proven and had a decent userbase.

Wow, my recent interest in MythTV appears to have been well timed. Apparently, Tivo now forces deletion of certain shows on your Tivo (although maybe it's just a bug; still...) This enables corporations to control what you can record and how long you can keep it. The screenshot of this "new feature" shows the patch is "in the wild" now.

It's funny, I was *just* talking with Kees about this exact thing last night. He had been remarking about how he was impressed enough by MythTV by its merits to justify switching to it; prior to yesterday he had assumed that his switch to MythTV would be "the day that Tivo starts restricting what I can record." So I think for Kees it's now MythTV is not only going to be a neat new thing, but also a necessity of principle.

Thinking more philosophically, I believe it is things like this that doom corporations in the long term. Each time they control, limit, and restrict what you can do, it's like they're contributing yet another feature on the side of Open Source. Each of these are a minor nusance for the consumer, picking off small bits of their freedom in the belief that it will gain the corporation a little more income. However, in reality these removals of freedom may be profitable in the short term, but it also turns people off of their service and motivates them to find easier alternatives. In the long run it results in a situation like we have with Microsoft, where you have a choice between a mediocre product with TONS of restrictions that have crept up on you over the years, and Open Source, that gives you every application you can think of, without all those annoying limitations, and at little or no charge, to boot!

Every time a corporation takes away one of your seemingly minor freedoms, it's like they're pounding a nail in their own coffin.

I'm lazy. After Yet Another Gentoo Installation, where I found my fonts were messed up (I'm picky too), and found myself thinking, "Now, what package was that font I liked in?" I decided to indulge my laziness and install *all* the fonts with stable packages in gentoo (or, at least, all the ones that would install.) Here's the command:

for font in `emerge --search font | egrep '^\*' | grep -v Masked | cut -d ' ' -f 3`; do emerge $font; done

If you're curious what'd be installed, just replace 'emerge' with 'echo', or just run 'emerge --search font' by itself.

Note that some of the fonts don't install easily (they require manual downloads of blah blah), but I figure I'm so lazy I'll just skip all those. Besides, if they don't install trivially, then there's probably something wrong with them anyway.

Finally, on the topic of fonts, let me take this opportunity to plug rejon's Open Font Library, a new project to do for fonts what our Open Clip Art Library has done for clipart. Imagine a HUGE, central repository of fonts of all sorts, under clear Public Domain terms, packaged in a way that allows you to select subsets of fonts based on your own filters. For example, select the highest scored font for each font face, plus all fantasy fonts. Or, select all fonts with fancy drop caps. Or, select all fonts that most closely (and legally) approximate the most common commercial fonts.

Granny Linux

Wow, I've gotten a lot more feedback on Granny Linux than I expected (all positive, too). I wish I actually had any spare time, because I think it'd be an extremely cool project and a great way to make life better for a LOT of people. Instead, I'll keep pitching out random ideas here, and hopefully maybe inspire someone with more time than I. :-)

From the feedback I've gotten, it sounds like the exciting part is not so much the stripped down interface but rather the administrative backend, and the notion that Granny Linux totally abandons the Windows-oriented idea of a single-user computer (thus forcing everything to be dumbed down to the lowest common denominator) and instead embraces the reality that for a basic end user, there are going to be people in several roles related to that machine. Each role can be specialized to certain desires and talents, and the system designer needs to design for each of these roles, and strive to make life easy for each. I.e., the user wants a consistent, reliable, simple interface; the first level admin wants simplicity of troubleshooting and configuring a single machine; the high level admin wants lots of options for customizing, testing, verifying, etc. across many machines.

Also, this whole concept is quite conducive to the idea of self-supported open source developers. The idea being that just as a person would hire a local professional to take care of their taxes, plumbing, or window cleaning, they'd similarly hire out their computer care to a professional computer engineer. I think there is already a fairly vibrant local tech support "industry" but much of that work involves relatively low-skill labor of scraping viruses off computers, reinstalling Windows, etc. With Granny Linux, the support load is divided into an even less technical level, and a much more technical level. The higher level is perhaps more in line with how your typical open source developer would like to spend their time anyway.

MythTV Club

Last night we had our second MythTV club meeting. We doubled our attendance from the first meeting too! :-)

Kees downloaded and installed the MythTV front end on his laptop, and dmandell, shiruken and I checked it out. Very purty. Kees (who has been a devoted Tivo afficianado) remarked, "Forget Tivo!" He was quite impressed. We went through the configuration settings; there's a lot of features you can turn on, and a lot of ways to customize them if you're unhappy with the defaults. Also plenty of ways to plug in your own scripts and tools.

One of the things Kees loves is that he was able to pull up and view his huge collection of music videos. He collects those off TV as a hobby, and this was the major motivation for him to write GOPChop. There were a few minor format issues for some of the videos, but he had ideas of ironing those out.

So, the question of whether to go forward with MythTV was unquestionably solved, and I'll be putting in the hardware order today. :-)

Habitat for Humanity

Brian, Kees, and I have decided to go volunteer for H4H here in Oregon one day next week. OSDL has a policy where if you spend one day vacation doing volunteer work, they match that with another day off to do the same. I think it'll be a cool way to put some energy into service and improve my carpentry skills in the process.

Today I got a call from my Mom about all these popups that are getting in the way of her being able to read email. Half an hour later, looks like the machine's got a virus. We're running McAffee now.

*Sigh*

It's not like we're not careful. I set her up with a firewall router, keep her (relatively) up to date with Windows security patches, have her well indoctrinated in using Firefox instead of IE, never running programs sent through email, etc.

I think I know where we slipped up. There was a website that wouldn't work properly under Firefox that she'd been using to help track some of her medical data, so I ran IE for just that site to retrieve her data so she could change to different software. My guess is that this one instance of running IE led to the infection; the timing was too coincidental...

Anyway, that doesn't matter; what I care about is that the machine got infected in the first place. It's stupid. I told her that I think we should convert her to Linux so we can put an end to these popups and virii once and for all. She sounded a bit uncertain about this; I think Linux sounds too hard core and scary.

I know it'll work fine, because we've converted a number of the office staff folks at work. The people have reported that it wasn't so bad, and while of course there are little incompatibilities and troubles, overall they seem to be able to get their work done, interoperate with people effectively, and so forth. Fortunately, we've got a really good desktop support guy who individually teaches each of them how to use it and walks them through everything they need to know.

My mom's at least as good with computers as any of them, and I'm sure she'd have no trouble. She pretty much just uses Firefox, Word, Excel, and a computer card game. All stuff that Linux can do just fine. It'll take a bit of social engineering to convince her to try it, but I think it'll work.

However, this has got me thinking even more ambitiously... What would it take to make Linux not just "okay" but the best possible operating system for someone even less technically able than my Mom and co-workers? What would it take to create a "Granny Linux"?

Here's my ideas...

First, the interface should be extremely stripped down. Granny Linux users are the polar opposite of the traditional Linux user - choice is bad. They probably only use about 4-6 applications, so there should be no other options beyond those, plus a button to turn off the computer, and a magnifying glass button. Firefox, one or two apps from Open Office, and a couple games. That's it.

If Granny needs another program, she calls her grandson and asks. He decides what to put on, and runs something remotely that installs and/or activates it.

Applications too should be stripped down. Grannied versions of applications would have most of the options ripped out of their menus. She doesn't need to customize her toolbars, she doesn't need to configure her javascript settings, she doesn't need to mail merge anything. If she does need these things, she calls her son or grandson and asks, and they turn it on for her.

I would also lay out the screen differently. Gone would be the panel and all its nifty gadgets. Instead there are big buttons in the corners to launch her applications. Corners are the easiest spots to hit, and with Granny's eyesight and arthritis, she needs all the help she can get.

Error messages on Granny Linux work differently than on a typical computer. They "know" that Granny isn't going to understand the technical jargon, so it doesn't bother to frighten her with it. Instead it gives her a friendly message that says that there is a problem, and gives her three choices. First, to ignore it. Second, to see more details about it. And third (and most importantly), to send the error to John (her son).

In fact, the cool technology in Granny Linux is all behind the scenes stuff. It leverages Linux's remote administration capabilities and then some. There are actually two classes of admin. The first is what we'd think of as first tier tech support. This is handled by Granny's son. He's essentially a power user, and knows all the applications Granny uses backwards and forwards. He knows how to troubleshoot a lot of the common errors. If she gets an email with an attachment, he can check to make sure it's ok. He's also patient about explaining again how to use the printer, turn off caps-lock, etc. If Granny needs a new piece of software, he can activate it for her and walk her through a canned tutorial over the phone to show her how to use it.

For more advanced things, like applying security patches, troubleshooting bugs, and so forth, they go to David, Granny's grandson. He knows Linux real well and is a pro at the commandline. He's comfortable sshing into her computer, reviewing logs, emerging/apt-getting software, and so forth. John notifies him when Granny needs help beyond the normal, thus escalating the problem to him.

It's this notion of a remote helper that I think would be the distinguishing feature of Granny Linux. It leverages Linux's ability to do remote administration and really puts a strong level of reliance on this remote admin, and strives to make *his* life easier.

For John (the first level tech support), he should have a web or gui control panel app that he can pull up to interact with her machine. This has buttons to activate or hide various software or capabilities on Granny's computer, change her themes, install fonts, review the error messages she's run across, browse logs, etc. etc. He can flag things for grandson David to look at, can upload new photos of the family's children to display on Granny's screensaver or desktop background, and see when Granny last logged in.

For David (the second level tech support), he has some options about how he interacts with Granny's system. First, he can ssh directly into the system and run all the usual unix commands through the console. Second, he can use the first level tech support app. Third, he can run a program that does aggregate administration.

This administrative aggregator is there to allow David to administrate several machines at the same time. In addition to his grandmother, he also has Granny linux on his children's computers, his wife's home machine, and 8 systems at his brother Earl's auto repair shop (Earl pays $50/month for the service, and considers it a bargain). Having to individually administrate all those systems would be a pain in the ass, but the aggregator allows him to ensure all the systems have the same versions of the same software installed, review and compare their logs (with ample use of diff to isolate differences between the machines), and so forth.

This system also hooks into a global database of all Granny Linux users. When an error message comes in, it automatically taps into it to pull up tips, suggested solutions, sample response messages, etc. David can often *click* *click* and invoke a script that addresses the issue or helps narrow it down.

David also runs a cute little panel app that shows a little indicator light for each of the remote machines. This tells him if the machine is on or off, changes color if the machine hits error situations, and blinks if it needs administrative attention. David runs this on his computer at work and both of his computers at home, so he keeps close tabs on everyone. He also has a program set up to send a text message to his phone in case he's away from his computer. The users are impressed that within moments after running into a strange error message they'll get an IM from David, "It's alright, you were just low on disk space. I've allocated a bunch more space for you, you should be fine for months."

Anyway, I bet the above wouldn't be that hard to make. I know that a lot of the pieces exist in some form already, and could be adapted to this. With something like Granny Linux, I think Windows wouldn't stand a chance.

Ted made an interesting point that Microsoft is failing to market the benefits of Windows, and instead seems to just be getting angry with people who are converting.

One of the features he mentions is Windows hardware compatibility. By and large, any random piece of hardware bought from a store is more likely to work properly with a Windows machine than it would with a Linux machine.

Of course, the more interesting question is, "How can we change that?"

Last week, Tridge and I had a discussion about exactly this. Tridge's idea is to create a distributed driver test farm, along the same ideas as the samba build farm (or distcc, or Seti@Home), except for kernel testing.

The idea's pretty compelling: I get ahold of some brand new (or old, or esoteric) piece of hardware that's unsupported under linux, stick it into a spare box, and run a shell script on the box that causes it to hook up to the distributed test system. Periodically, it gets told to download, compile, and run some new kernel code and tests, and rsync the results back up to the server. A fwe weeks later you pull the card out and put it in your main box, upgrade your kernel, and presto! it's now got full support and a lot of testing.

Of course, it gets interesting when you think about the details. What if the kernel panics, wedges, or otherwise goes out to lunch? There's a few ideas for this - software/hardware watchdogs, kexec, grub fallback, etc. I've been fiddling with these ideas a bit this last week (no eureka's so far, but still much to learn.) As a last resort, I suppose we could just encourage everyone to invest in a remotely controllable UPS so the system could power cycle their hardware as needed; this seems inelegant (and possibly hard on the hardware), but might be the ultimate solution.

I'm also curious about the testing itself. Initially, we could just do install tests (just load and unload the module), but I think ultimately we'd really need a crapload of tests. Maybe a given test could work across a range of drivers, but even so I imagine we'd be talking about a LOT of tests. Recruiting enough people to write enough tests seems like it'd be a challenge.

Yet despite the devils in the details, this idea has a huge upside. Imagine helping Linux beat Microsoft at its own game, and steal its #1 best feature? Imagine having MORE confidence plugging some random dohicky into your Linux laptop than you'd have plugging it into a Windows system? :-)

Aside from the boot robustness / power cycling functionality, I think it would not really be all that difficult to do. The code to do a test farm like this is a little complicated but nothing we've not done before. A lot of us hardcore geeks have at least one spare box sitting aside that they'd probably be willing to devote to this cause. And I'm sure like me you've got a random assortment of hardware that doesn't quite work right on Linux, (and probably some old stuff that doesn't work under Windows anymore either!) So the hardware should be doable too.

It's great to see the summer of code projects wrapping up. They've sure been effective at injecting some really interesting new features into Inkscape that I think users are going to be impressed with.

Also, it sounds like the students have had a good experience and felt included as part of the team. I've long felt that having an open, friendly community is the best way for an open source project to become prolifically successful, and I'm always happy to see the evidence at work. :-)

MythTV Club

I love Tivo. I want a Tivo access everywhere that I have a TV or computer, but of course the idea of buying a bunch of Tivo's and paying an extra $7/mo each seems just silly.

So I got thinking about it, and decided that MythTV is the way to go. I mean, setting it up shouldn't be a big deal; after all I install Linux on funky hardware all the time at work for testing NFS, and MythTV sounds simple in comparison. Besides, I know Kees, the guy who builds cables for disposable camcorders, develops MPEG2 editing software, and analyzes the Tivo file format for fun.

Of course, the devil's in the details and neither Kees nor I really relish the idea of gaining another project that takes tons of time for researching and tweaking. But we got to thinking and decided, why not set up a MythTV club at work. We know several other people who'd be interested in learning/experimenting/fiddling with it, and by being able to share notes and tag team on problems, it seems like we ought to be able to get it figured out pretty easily. Maybe we could even come up with some improvements to contribute back.

Several people on planet.inkscape.org have shared thoughts about the hurricane. If there is any silver lining to this disaster, it's that it's caused people to think more intently on issues such as the limits of our global oil supply, global warming, the ugly face of racism, and the fragility of our society in the face of natural disasters. I think a lot of people are really wondering at the clear failure of leadership shown in this disaster. I truly hope that people who believed that global warming, racism, and oil are not problems, or that are problems we can ignore, finally understand they are real problems that all of us have to find ways to solve. I also hope that people see that whatever your political beliefs, we desperately need a better national leadership than we currently have.

In ancient Greece, democracy was more than just voting for a candidate, as often seems to be the limit of American democracy these days. An important aspect in Greece was the notion of 'accountability'; the Greeks put as much (or more) emphasis into making office holders responsible for their actions (or lack thereof) as for selecting them for the position. I hope there will be accountability for those leaders who have failed to provide swift help to the victims of this hurricane, and I hope that the problems are fixed before our next major disaster, because scientists like those who predicted this "worst case scenario" have predicted other scenarios much more dire that may well lay in our near future.

Today I implemented a new RSS feed mechanism for Inkscape. We'd been using WordoPress, but hardly anyone was posting news, and I found it too inconvenient to use and wasn't really posting much news myself. Before WordPress, we'd been rating a news item every few days very regularly, which users loved to see and set Inkscape apart from many other open source projects that rarely updated their homepage; ironically and unfortunately, while WordPress was in use it was unusual to see more than a couple news items a month.

Anyway, I finally decided to switch us back to the old system and get back to doing news items. Obviously this new system was not working for us. The two issues that had been identified with the old system was that it was hard for people to add news, and that there were not RSS feeds. For the former issue, WordPress may have made it easier for people but clearly there weren't enough people taking advantage of it to make it worthwhile.

The second issue was more problematic, and I quickly started receiving "bug reports" that the RSS feeds were broken after I started posting news items. Hrm.

So like any good Perl hacker, I hit cpan.org and found a handy dandy Perl module XML::RSS::SimpleGen, which automatically generates an RSS feed from an HTML page. This makes a static .rss file once an hour, which will make the Inkscape homepage more robust in the face of a slashdotting (we got hit during the 0.43 release with more traffic than WP could handle, and the homepage and rss feeds became unreliable).

Anyway, I'm also looking at using this for syndication of test results. The NFSv4 developers had requested such a capability a couple months ago. Also, my manager at work thought this would be a nice-to-have for our department, so we could present all of OSDL's testing news and data in an aggregated fashion.

http://www.bryceharrington.com/dms_list.png

This is a cgi app running on my local box, that accesses the DMS server running on freedesktop.org and retrieves a list of 20 documents (unsorted), and then prints out a table of their basic metadata.

http://www.bryceharrington.com/dms_update.png

This shows updating a document's state (new, accepted, rejected, broken, etc.) You select the new state and click submit, the web client then submits the update request through soap to freedesktop.org, then when you reload the list view, the state is updated correctly.

On Friday, Carl Worth gave a Cairo tutorial. He went through the Cairo API and explained what each function did, and we played with several example files to see how to draw shapes, write text, and so on. He showed how the same code could be used for drawing to the screen as well as to generating postscript output. The tutorial plus the required dependencies are posted here:

http://cairographics.org/snapshots/

It was a very enjoyable tutorial. I learned a ton and found it quite inspiring. After the tutorial I browsed through the Inkscape codebase and got a little bit of an idea on where Cairo would plug in, and what sorts of changes would be needed to get us there. Migrating to Cairo looks like a lot of work, but it also sounds like it'll be quite fun.

Cairo is still in heavy development, and the focus to date has been on getting correct results moreso than optimization. I got a copy of ScislaC's Gaze SVG image for use as a stress case, and Carl and I tested cairo on it, and compared its rendering and performance with Inkscape. Cairo rendered the file badly, making ScislaC's fairie look like some undead creature. Carl found out that this was caused by a small bug in Cairo, which he's now fixed, and the image renders well. Carl measured that it took 48 seconds to render this with Cairo, compared with around a second or so by Inkscape. Carl will be able to use this file as a performance test case, with the objective of getting the performance down within range of Inkscape. He feels confident that between liboil and some profiling, this should be very doable.

I don't know if there has been very extensive comparisons of livarot and cairo, but my own tests and the informal testing I've seen others do seems to indicate that cairo is pretty close to livarot in terms of rendering functionality, however I'd want to see much more testing before we can say for sure. I'm confident that if any differences do emerge, and if cairo is found to be incorrect, the issues are going to get fixed swiftly. I don't think Cairo would be a drop-in replacement for livarot; I think there is additional code that livarot (and libnr) has that is out of scope for Cairo, that we'd need to repackage somehow and use, but it will take some investigation to identify what these things would be specifically.

The big news at the conference was the integration of GNOME/librsvg and cairo. Several people were experimenting with use of cairo for rendering the desktop widgets and such. Currently, it appears that Cairo development is heavily focused on supporting these efforts. Thus, Cairo seems to have reached a point where it is a viable replacement for the libart-based rendering code in librsvg, and work is progressing with that goal in mind.

However, note that the librsvg SVG backend that is under development isn't precisely what we'd need for Inkscape. The 'r' in rsvg implies that it's designed for single-pass-through rendering such as is needed for static SVG displays as you'd need for widgets and desktop stuff. Since Inkscape is an editor, what we need is a 'dynamic' SVG renderer, that allows us to interactively alter the drawing as the user moves things around, adds new drawing elements, updates style definitions, and so forth.

The good news is that Cairo itself is designed as a dynamic drawing library. It does not hold state on the items being drawn, and depends on higher level code to track the drawing elements. Thus, what we'd need to do is establish something like Inkscape's Repr and shape hierarchy, but have it render by making cairo calls instead of libnr/livarot calls. I think this will touch a LOT of the Inkscape code, but on the plus side by replacing the rendering code it should really cut down the amount of code we will have to maintain inside Inkscape.