Chaotic clamoring

Processing and Processing-JS on the BeagleBoard under Angstrom

2011-04-04T21:51:00.000-05:00

After reading the blog post about the serial port challenges in Processing and the method for fixing them, I decided to download the IDE and try it myself. It seems to work reasonably well. I haven't quite managed to learn enough about the Arduino to understand how they use Processing or how limited their implementation of it is, but I was able to install and run the Arduino tool on my BeagleBoard after applying Koen's serial port library fix. I hope to use the tool to download applications onto my Trainer-xM, but I haven't yet been able to compile the examples natively because I haven't yet built avr-gcc.

This is highly related to my current personal project, which is working with Processing-JS. I've been talking a lot about a BeagleBoard Linux Education project, but haven't really kicked the project off after working with others on the scope. Mark Yoder's ECE497 class is where the most visible advancement seems to be taking place right now, though I've heard of several other educators also creating courses with the BeagleBoard, including the Stanford New Musical Controllers workshop.

For me, I like the ideas of avoiding compilation, working in the most popular development environment today (the browser) and being able to remote my interface anywhere in the world over the web. I also believe the zero-install nature of web applications and the familiarity of working within a browser make it the perfect environment for newbies. To that end, I've made a little fork off of my Linux education project to focus on JavaScript-based development. I now have both Cloud9 and Processing.js installing as submodules. Under Angstrom, I'm able to easily run Chromium as one of my browser options and see the output from Processing.js, such as the picture here. Now to see which environment gets me talking to my Trainer-xM board first.

Also, sorry about the delayed BeagleCast this week--resulting in some of the topics not being timely. I've had a challenge getting a call scheduled with Khasim to discuss Rowboat.

Node.JS-based Cloud9 JavaScript IDE running on a BeagleBoard

2011-03-07T14:11:00.000-06:00

Yesterday, I decided I was going to get Cloud9 running on my BeagleBoard. I didn't document every step, but below are a few helpful hints. I'm working with a recent Angstrom Distribution build with Node.JS v0.2.6.

At first, I tried using Node.JS v0.2.1 and I found that the 'connect' module wasn't present. I went to install 'npm', but the install attempts failed silently. When I found that v0.2.6 was in the feeds, I tried installing 'npm' again and it succeeded without much of a headache. I installed v0.2.19 of 'npm'.

Since the node-o3-xml package needs to be compiled for Cloud9, I installed a bunch of native tools onto my BeagleBoard, including 'opkg install task-sdk-native nodejs-dev', but I don't remember 100% of what I installed. My confusion began around an error on 'import Scripting' when running node-waf. Fortunately, someone already figured the issue out for me when they were trying to build node-inotify on a Gumstix board. I installed the extra Python tools and copied the .py code from my Mac. I did need to edit wscript to remove any x86 specific optimization flags and remove any .pyo files that accidentally got copied over.

Once I built o3, I installed it into my Cloud9 directory, which I checked out following the online directions. I am working from the Cloud9 0.2.0 tag. Since the submodules of Cloud9 include a set of pre-built binaries for o3, I added a repository that included my newly built ARM binaries.

I think this was pretty much it to getting Cloud9 invoked, but using the latest Firefox 4 beta as a client wasn't working. I tried using the '-d' flag at invocation and moving Cloud9 to a user account instead of root, but that didn't help. Based on a blog post that described invoking Cloud9 on an Ubuntu machine, I was using this command-line to perform the start-up:

node ~/cloud9/bin/cloud9.js -c ~/cloud9/config.js -w ~/testproject -d

I decided to install Chrome to see if it was a browser dependency and viola!

After a simple web server app, I decided to poke the LED SYSFS entries. I needed to change the SYSFS file entry permissions to 777 to enable my user account to set the state, but I was easily able to do so.

Next step is to show how JavaScript closures can be used to create a web page that responds quickly when the USER button is pressed, generating a Linux input event.

Am I the only one that gets how cool it will be to be able to distribute pre-configured SD cards you can drop into your BeagleBoard, plop it onto a network and start editing code to peek and poke hardware using an IDE without ever installing *anything*?

Google kills Blogger Web Comments

2008-07-19T11:00:00.004-05:00

Often I find websites where people are just being stupid and need to be told so. In those cases, I don't think relying on the ignorant host of the site to provide a comment page to let me tell him how much of an idiot he is being will really work.

Then there are those cases where I'm wondering about what other people think who are interested in this same site that doesn't allow direct comments to be posted, or where I don't trust the host to not pull down negative comments.

So, what are my options?

Well, I used to make a lot of use of the Blogger Web Comments for Firefox. This was a pretty handy tool that would fetch comments using Google's Blog Search. Since I've recently upgraded to Firefox 3, I thought it was a good time to go look for an update to the plug-in and to see if I could get that functionality back.

Unfortunately, the plug-in is no longer available. This isn't the first time I ran into a brick wall with Blogger Web Comments for Firefox, but it seems they've decided to drop it, rather than fix it.

Hopefully others will still see the promise in this sort of functionality and provide something, but in the short term, I'll be stuck performing copy-paste operations and executing 3-5 clicks to get similar output manually from del.icio.us, Google blog search, and Technorati.

I'll be visiting those search options regularly to see if someone picks up on this feature.

Coining a phrase, the Contextual Web

2008-03-30T12:46:00.005-05:00

I was getting started writing up a "master paper" to serve as a guideline for submissions to several conferences this year, including Lug Radio Live USA. In this paper, I planned to coin a phrase, "The Contextual Web". I figured, if I plan to coin a phrase, I should at least ask Google if anyone has tried to do that before me.

It turns out that someone has, they did it recently, and the synopsis looks eerily like the one I had written in some drafts. I'm not trying to claim that anyone stole my idea, or that I even had it significantly earlier than anyone else. To the contrary, I'm trying to claim that this idea is just that obvious. Here's a clip from the page I found when I did a Google search for "the contextual web":

The next generation of the web isn't going to be on your desktop, it may not even be on your mobile device. Context is going to be increasingly important and Nick will take you through the process of designing and architecting for context as well as regardless of the context.

Well, Nick Finck, you've got my attention. A few more searches with Nick's name in the search box return some additional gems:

There are four Elements of Context – the User, the Task, the Environment, and the Technology. Who is your user and what obstacles are they facing; what task are they trying to complete; what is the environment in which they are working; and what kind of computer or device are they using? Designing interactive experiences is not limited to the web on your computer or phone – consider gas pumps, fridges, or devices like Microsoft Surface.

This definitely puts my ego into perspective. Nick, I'm supporting the Beagle board just for you. :)

Adding a URL to 'gitweb'

2008-03-21T23:22:00.001-05:00

It is as simple as creating a 'cloneurl' file in the git repository directory, just like you can add a 'description' file.

This took about 7 minutes of exploring the CGI code of gitweb to find, which took another 2 minutes to find. I spend about 20 exploring the web based on some links I was given that were 'supposed' to explain this, because this was the big feature that was missing from my gitweb installation. Ugh!

Come on Linux folks, are you just trying to make easy things difficult?

Example: http://www.beagleboard.org/gitweb/?p=beagleboard.org.git as sourced by http://www.beagleboard.org/beagleboard.org.git.

Making the connection between Gears, GreaseMonkey, JXTA, and OpenID

2008-03-20T09:59:00.002-05:00

A while back, I wrote-up a "Collaborative GreaseMonkey" patent disclosure. It was a defensive measure to make sure no one else patented the idea and prevented the rest of us from using it. The disclosure never made it past our patent committee, and I think that is fine, since it is at least documented as prior art in some way. The code never got to the point where it was worth sharing, but I do plan to revive it at some point.

I'm seeing that more and more people are starting to get ideas that are more and more similar to what I had in mind. Today, I read about someone dreaming up thoughts on using Google Gears to perform OpenID and OAuth. I like the thought pattern.

Gears, GreaseMonkey, OpenID, and P2PSockets (JXTA) have the potential to re-invent the web and to establish a real web operating system. Gears enables the JavaScript written into web pages to become part of a real, persistent application with persistent data storage and threads. GreaseMonkey provides a solution to edit existing web applications with user-controled, local customizations and to create applications fully local, without needing to learn how to write a web server application. OpenID gives a single solution for authenticating yourself across those web applications. P2PSockets allows the applications and data you host locally to be discovered on the web without needing to own a web server.

The result is an application building environment that is an incremental step from simple HTML+JavaScript editing and allows everyone to invent their own web, rather than just rely on the web that the social networking sites control today.

The success of this web is, of course, controlled by the economy it creates. An a-la-carte business model, like the one provided by Amazon's web services, is a great way to ensure that the bandwidth and data storage necessary for the locally-hosted services to scale.

Thoughts?

Open source on TI devices

2008-03-07T10:32:00.002-06:00

I happen to like this article, TI targets Linux and open source with new OMAP chips, but I certainly have gotten the message "more patches, less powerpoints". We'll see over the next few months...

TI-Open-Source-Workshop-TIDEVCON08

2008-03-05T22:30:00.001-06:00

TI-Open-Source-Workshop-Jason-Kridner-TIDEVCON08
Originally uploaded by shutter_nut

I've mostly given up on trying to be relatively anonymous on this blog. I figure that people who know me already know how to find this site, but I'm starting to try to take on some relatively public responsibilities related to open source software and the newly "announced" BeagleBoard.

Actually, the BeagleBoard isn't officially "announced". The reason is that there really isn't a community or set of applications around it yet to make it something worth announcing. Instead, it is just an open project looking for some of the right folks to help make it happen.

I have a lot of confidence that the BeagleBoard will be a very real and active community project. Just let me know if and how you'd like to get involved.

For those who have read my blog posts in the past, rest assured that the BeagleBoard is quite intertwined with my vision for collaboration. My hope is that it will yield a nice starting point for building collaboration software that could be integrated into just about any form-factor and innovative human interface.

Heading to LugRadio Live

2008-02-06T09:07:00.000-06:00

You almost can't call it a business trip, but I will be filing an expense report...

Go to LugRadio Live USA 2008, 12-13 April, San Francisco! Watch this, then spread the word!

Could Pandora open up Linux games?

2008-01-29T18:21:00.001-06:00

They say the Open Pandora (P&|A) handheld gaming device compares in power to a Nintendo GameCube, and will offer full-speed Playstation and N64 emulation. How does the GameCube compare to other systems/CPUs?

Of course, what I think is really interesting about this device is it being a clam shell (to protect the screen), having real gaming controls, and being fully open for hacking. I expect a lot of nice software will come out of this device existing.

read more | digg story

Hello? Jabber was designed for cloud computing

2008-01-24T22:00:00.000-06:00

I just read Marshall Kirkpatrick's Read/Write Web post Could Instant Messaging (XMPP) Power the Future of Online Communication?. Despite his apparent bemusement with the "the rise of XMPP (called Jabber in IM) for powering communication services hosted in the cloud" this really shouldn't be much of a surprise. In one of my favorite books of all time, Peer-to-Peer, Jeremie Miller, inventor of Jabber, explained this to the world in 2001. Jabber was envisioned from its beginnings in 1998 to not just handle person-to-person conversations, but also person-to-application and application-to-application conversations.

I also recently read about using Jabber with my OLPC XO-1, which opened up a whole new world. All of a sudden, instead of just finding other XO's on my LAN, my screen was full of people to chat and collaborate with. Over Jabber, not just instant messages are shared from the XO, but every application can be shared and becomes a gathering place. You can take a look at how Jabber is used with the XO on the OLPC wiki.

Marshall goes on in his analysis to bring us back down to Earth regarding Jabber/XMPP relative to HTTP and he is right. HTTP rules today and I don't think there is any one killer reason to change that. If nothing else, however, Jabber/XMPP has a really nice specification on how to use HTTP more efficiently to get notifications without polling. Jabber/XMPP specifies this for the purpose of overcoming firewalls, but the result is that Jabber/XMPP can really be seen as simply some really cool stuff to do on top of HTTP.

Where is the Jazelle-RCT open source solution?

2008-01-23T11:03:00.002-06:00

Ugh. There is too much noise around open source virtual machines, including almost 16,000 projects on SourceForge.

The PhoneME, Android, or other open source JavaVM projects must be looking to support ARM's Jazelle-RCT technology, right? I know there are some interesting commercial efforts, but if anyone is aware of an on-going open source project, I'd want to hear about it.

Bug Labs device was cooler than I expected

2008-01-10T20:37:00.000-06:00

At CES this week, I managed to stop by the Bug Labs demo, which ended up winning an award for the best emerging technology. I've been hearing about this device for months from co-workers and I'd explored the website, but seeing the live demo was more impressive than I expected.

The little Lego-like embedded electronics development kit was quite flexible. As a challenge, in 8 minutes, they created a new application of a motion-triggered camera that would upload photos to a server. I was quite impressed.

They use Eclipse to create an easy-to-use development front-end and PhoneME to run Java applications on the device. The device is running both X11 with Athena Widgets (AWT) and Qt/Embedded. This isn't quite as nice as the GTK stuff running on the N810, but it shouldn't take them any time to get there. The demonstrator had no trouble throwing together a new program in Java and sending it down to the device over USB, despite being harassed by one of his co-workers about the missing award they had just won.

Apparently, someone decided to take their newly won prize. Hopefully, it was just on loan to one of the many television interviewers showering attention down on them.

Criticism of the OLPC XO-1 concept

2007-12-13T09:09:00.000-06:00

In John C. Dvorak's PC Magazine article "One Laptop per Child Doesn't Change the World", he writes:

Does anyone but me see the OLPC XO-1 as an insulting "let them eat cake" sort of message to the world's poor?

I like Dvorak and I often follow him on the TWiT podcast and CrankyGeeks on TiVo, but he polarizes issues in ways that sometimes aren't that useful, except for bringing attention to an issue. Hopefully the audience is paying enough attention to think for themselves, but that has proven repeatedly not to be the case.

In my view, if some service like "Mechanical Turk" pays living wages for these folks, then it was worth it. On average and over a lifetime, each of these students should be able to earn more than the cost/value of the computer.

Yes, the literacy rates and language barriers are an issue in making the computers useful at all. There would be, however, huge motivation to focus on literacy and additional languages, if some people are able to earn money with these machines.

So, Dvorak has given all of us XO enthusiasts a mission: enable students to make money using these machines by providing services like Mechanical Turk in the languages of the students and figure out how they can collect the resulting goods.

OK, I admit, this isn't a perfect idea. I've heard concerns that these laptops will be stolen if a market emerges for them and having them be a source of money would certainly make them valuable. This is also, to a degree, advocating some sort of child labor, which is a reality, despite the many objections we have in the developed world.

Better ideas?

Blogger Beta Ships OpenID

2007-12-01T08:34:00.001-06:00

Google has added new login options to Blogger, including OpenID. This is an important additional baby step towards a web with a single sign-on that allows you to have better control of your identity information.

read more | digg story

N810 demo video from Nokia

2007-11-20T17:13:00.001-06:00

Nothing too special about the web page, but the video gives lots of good angles and pictures of accessories. Sure would be nice if they used that GPS and a database to help find some WiFi hotspots. Too bad it doesn't have WiMax or EV-DO.

read more | digg story

Accessibility is the killer mashup/webos application

2007-10-01T13:03:00.000-05:00

After watching Douglas Crockford (of Yahoo and JavaScript fame) plea for Google, Microsoft, and others to participate in a mashup summit and reading some of the feedback around the web, I realized the critical application use-case is still missing.

Someone in the Q&A brought up a good example of a mashup implemented today in an undesirable method due to security reasons: Facebook accessing your GMail/MSN/... contacts to request more members. Contact sharing between applications is an excellent use-case for mashups, but I don't see it as a driving application. Certainly it gets to the heart of Crockford's talk: security is an excellent application for the Google Gears WorkerPools. If you are like me, you'll still be left thinking about how everyday web consumers will be motivated to download Gears, instead of walking down the questionable path of simply giving applications like Facebook access to all of your potentially private information.

Mashups are the most interesting innovation in software development in decades. Unfortunately, the browser's security model did not anticipate this development, so mashups are not safe if there is any confidential information in the page. Since virtually every page has at least some confidential information in it, this is a big problem. Google Gears may lead to the solution.

Security is important and is critical to the growth of new mashup applications and I'll be happy if that alone brings us worker threads and off-line support, but I think the killer mashup is the one that makes all of this great data exposed through APIs and structured web pages and makes it accessible in new ways.

Mark, of diveintoaccessibility and diveintogreasemonkey fame, who I admire for his vision of accessibility wrote in his blog post "if wishes were iPhones":

I don’t understand this continuing obsession with buying things that you need to break before they do what you want.

And with this thought I am reminded that the killer mashup/webos application is the one that takes all of those immensely useful web services out there and makes them measurably usable. And by usable, I mean giving the user control.

Mobile 2.0 Conference

2007-09-10T01:04:00.000-05:00

I'm thinking about trying to attend the Mobile 2.0 Conference on October 15th in San Francisco. Anyone have comments about this event? If there were a handful of people interested in chatting about how to enable creation of scalable web services generated from mobile/embedded devices, I'd make a point of going.

No server, no satisfaction

2007-09-06T09:17:00.000-05:00

There's just no satisfaction for the casual home user who wants to collaborate with friends. Even when dealing with a problem that has been solved many times over, it is really difficult without a server of your own and a fair amount of programming. The problem I'm talking about is planning events on a group calendar.

There is a group of somewhat over 25 people near where I live that frequently gets together to play outdoor roller hockey. We play in a parking lot in one of the area parks or offices. We have a mailing list on Yahoo, but most people are just copied on a repeatedly used e-mail thread. On that thread, the subject line is typically changed to match the proposed day and time. Every week, we all bombard each other with e-mails to make sure that enough of us are coming out to play. This has actually worked fairly well, but there have been some significant exceptions.

Sometimes we don't meet our threshold of 6 players and additional e-mails go out to entice people to sign-up to play. Calls are made. Threats are discussed. People who previously agreed to go attend might decline since they don't want to risk trying to play hockey with only 3 people. Chaos ensues.

One of they guys who used to come out regularly created a really simple sign-up page on a website. The site accepted a name, e-mail address, and phone number to sign-up for a given game. The name is listed beside the entry for that game. The e-mail was used to send out the "game-on" or "need-more-players" notification a few hours before the prospective game. Phone numbers were included to speed up the communication.

The application worked quite well and was simple-minded. Entering the same sign-up information twice would result in being removed from the list. The phone number and e-mail information had to match, providing a tiny amount of security from folks simply removing everyone from the list. No verification of the entry was done, but you can imagine a simple verification code being provided via SMS to the mobile phone number if we ever started to have problems with that. Life was good.

He stopped playing and his site stopped working. We were back to using e-mail. A few folks reminisced about the good 'ol days when we had our own web server. I own the domain name, so I decided to bring back the sign-up sheet. Where should I host it?

I don't really like the idea of pointing people to my home computer, so that's not my first choice. I don't really like the idea of paying for a full-featured (LAMP and/or Ruby enabled, ie. scripting and a database) hosting service just for this hobby. This is just calendar data! Why should I need a web server to do something that Yahoo and Google provide for free?

Our mailing list is on Yahoo, so I looked first at their group calendar. It was a disastrously complex to use and didn't provide any of the custom features we had with the much simpler web app. Similar problems were had with Google's calendar and Evite. The most fundamental issue with all of these calendaring solutions: they required account creation and login to utilize.

I tried to see if I could do something with static hosting, but it seems even Amazon's simple queuing service doesn't seem to work without having a dynamic host. At this point I gave up, but I'll get back to this application yet.

Still don't get the whole WebOS thing?

2007-09-03T08:39:00.000-05:00

I've gotten a bit smarter about explaining why there will be a sort of emerging web operating system to the people who inquire. For example, I've started calling it a "web services kit", instead of an operating system. Today's tech savvy minds can accept the idea of yet-another-SDK, whereas the idea of a web operating system is either tainted by the webtops or seen as inconceivable and unnecessary delusions to compete with Windows, Linux, or OSX.

What I haven't leveraged enough is the great summary of web service APIs provided by ProgrammableWeb. From their simple scorecard, you can get a quick overview of the categories of popular services and some of the key players. Ask yourself what sustainable advantage do any of these players have within their service space. Don't get fooled, it isn't an easy question. Keep in mind that standard service definitions are coming into existence for most of these services, such as XMPP for chatting and OpenID for identity. Take up the exercise to look across these service APIs, look for winners, and look for emerging standards.

Comfortable? Now, realize that it is only a matter of time before there are standards-based implementations of all of these services. Sure, it might take a while, but it'll happen.

If you are quick, you might be sighing and thinking to yourself, "what about the data?". I'm glad you asked, because that is really the point. These services are all about controlling access to data and looking for ways to monetize it. You might stumble over the idea that on-line office applications involve an incredibly complex pile-o-code, but then you'll remember that you already have 2-3 other viable choices of office applications to which you already had access. Over the long-term, it is all about the data.

Still don't feel like you're any closer to accepting the idea of a web operating system? That's okay, as long as you recognize the benefit of something that provides you with the capability to control and monetize access to data and some sort of well-understood integration layer back into your application. You'll come around when you start thinking about who you want to own your data.

BarCampHouston

2007-08-25T07:05:00.000-05:00

I'm heading up to BarCampHouston today. I don't know what to expect and I haven't had any free time whatsoever, so I won't put on much of a demo or presentation. I'll be happy to share any info on P2P collaboration and my Maemo SDK EC2 image, if anyone is interested. I'm also looking forward to simply discussing toolkits for building web services (web operating systems).

By the way, I've moved my EC2 script over to http://sdk-ami.garage.maemo.org.

Boot your N800 Maemo SDK today with Amazon's EC2

2007-08-18T01:01:00.000-05:00

I really appreciate that someone has created VMWare and QEMU images for running the Maemo SDK. Unfortunately, my machines, both Mac and PC, are typically too busy with other stuff to allow me to quickly fire-up a virtual machine image that will chew up all my computing resources. Instead, booting up a machine from Amazon for about $0.15/hour or so is affordable enough for my N800 development. No more downloading a 1.5+GB image; EC2 users can instead just share an image and a boot script and be up-and-running at a known-good starting point.

Of course, the first step was to get an EC2 (and S3) account. I waited almost a month for my EC2 account. At some point I'll figure some way to let other people just rent a machine from me to make it easy, but that'll require a bit of thought and management. For now, head on over to Amazon, request an account, and they'll get to you eventually. There isn't any monthly fee or hidden costs; you just pay for the time, bandwidth, and storage you use. As long as you copy your work off somewhere else, such as by using Subversion hosted by code.google.com, you can shutdown without having any recurring fees.

Once you have an EC2 and S3 account, you'll want to download the EC2 command-line tools and your access identifiers.

The next step was to choose the Linux image I wanted to use as my starting point. Personally, I'm a Gentoo fan because I think Linux has an excessive number of binary-compatible dependencies on the C library and Gentoo solves that by recompiling every new application, instead of needing to update your C library to match the binary-compatibility requirements of all your applications. Of course, that makes application installation slow and Maemo itself uses the Debian package model, so Debian or Ubuntu make the most sense. However, Amazon supplies some nice reference images on Fedora Core 4 that might simplify my life around issues like ssh login security when the root account password can't be secret. Nothing is easy, so I found an Ubuntu image that has reasonable documentation on how it was created such that someone could redo this all with a better supported AMI in the future.

At this point, the issues started to pile up and I decided my best hope was to document my steps in scripts so that I can reproduce them with a better starting image and make corrections that people point out to me. I decided to the Google Subversion server I mentioned earlier to host my script at http://code.google.com/p/maemo-sdk-image/.

I used a Mac to run my script, but I plan to eventually make it run on the N800 itself or on a Windows PC. Right now, the script uses bash, which isn't natively on either the N800 or Windows. Also, the Unix-style version of the EC2 command-line tools also utilizes bash. I think the solution for both is likely to install bash.

The access identifier information ended up placed in a subdirectory called 'secrets' under where I ran the script. These secrets end up getting copied temporarily to the EC2 images for the purpose of bundling them up. I exclude that directory from the bundle.

I say 'images', because I end up working with four different EC2 images in the script. The first one is the base Fedora Core image that Amazon makes public. The second one is a bare-bones Ubuntu Feisty image that can be boot on EC2. The third one is patched to be self-bundling. The fourth one actually contains the Maemo SDK. The third and fourth could easily be combined, but I am still inching along.

In theory, you can run all of the steps using 3 separate calls to the script:

./build_maemo_api build-feisty
./build_maemo_api patch-feisty
./build_maemo_api install-maemo

I think the first two should work reasonably well to create a self-bundling Ubuntu image, but I haven't run them exactly like that to test them out yet.

The third step certainly won't work. One issue is that the Nokia binaries require you to agree to a license, so you'll need to do that part manually. This also only gets you to version 3.1 of the SDK, so you'll need to update that as well. There are also several steps missing before the image is really usable, such as setting up the X server and VNC server to allow you to view the emulated N800 screen remotely.

Please feel free to post your comments here or on the wiki on how to improve the script. I won't hesitate to utilize your inputs on the script hosted on the Subversion server.

Working on an Amazon EC2 AMI for the Maemo SDK (scratchbox on Ubuntu)

2007-07-27T12:50:00.000-05:00

I'll get into why I want to create this Amazon EC2 AMI thing later, but I thought I'd get information out there on a problem I'm having. Tve did a nice write-up on RightScale on bundling-up an ubuntu EC2 instance. This is a really helpful write-up, but I get a shell script error and a hang when I try to bundle my Ubuntu image.

root@domU-...:~# ec2-bundle-vol -d /mnt -k ~root/pk-....pem -c ~root/cert-....pem -u ...
Copying / into the image file /mnt/image...
Excluding:
/sys
/var/lock
/dev/shm
/proc
/dev/pts
/proc/sys/fs/binfmt_misc
/var/run
/dev
/dev
/media
/mnt
/proc
/sys
/mnt/image
/mnt/img-mnt
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.003492 seconds, 300 MB/s
mke2fs 1.39 (29-May-2006)
warning: 256 blocks unused.

Bundling image file...
sh: Syntax error: Bad substitution

The script keeps running. I don't know Ruby well, but the script seems to be stuck in a shell call to 'openssl'. This seems to occur in bundle.rb line 51. It looks like the 'tar' call on line 57 that is meant to feed the pipe being read by the running 'openssl' died, but I don't see where the "Bad substitution" might be.

Tve didn't have a place to make a comment on the blog entry. Time to debug...

Quick update on when I canceled the process (need to think if this confirms or denies what I was thinking):

sh: Syntax error: Bad substitution
sh: cannot open /tmp/bundleimage-pipe1: Interrupted system call
error executing tar -chS -C /mnt image | tee /tmp/bundleimage-pipe1 |gzip | openssl enc -e -aes-128-cbc -K ... -iv ... > /mnt/image.tar.gz.enc; for i in ${PIPESTATUS[@]}; do [ $i == 0 ] || exit $i; done, exit status code 2
ec2-bundle-vol failed

...need to take a break and get back to my real work.

Update #2: The problem turned out to be assumption in Amazon's Ruby script that 'bash' would be the shell executed by default. The answer was within a script found on the Amazon developer's forum. I've created my first image and I'll be hosting my script using Google's open source code repository when it is done at http://code.google.com/p/maemo-sdk-image/.

Judgment vs. Jealousy: Jadon on Twitter

2007-04-27T02:07:00.000-05:00

After hearing so much talk about Twitter on the blogs, podcasts, and vlogs I read, hear, and watch, I decided I had to know what the fuss was about: http://twitter.com/Jadon. How do I manage to find time for this sort of waste?

Google AJAX Feed API

2007-04-19T01:01:00.000-05:00

I read Udi Dahan's post on how Google's Ajax API Simplifies Safe Mashups. It didn't take 5 minutes to take Google's "Hello World" AJAX Feed API example and embed into a web page of my own. This is fun stuff allowing me to finally be able to manipulate feeds across sites without injecting any server-side code.

What should be noted is that this is relying on Google services and must follow their terms. It means that they monitor all the content this API brings into my page while other search engines cannot. (Crawlers do not typically execute the JavaScript, so that's why they wouldn't see the results of the API calls.)

Certainly I'm not the only one disturbed by this, right? Where is the counter-movement to give the every-blogger ownership of his own services in just as simple a manner? Is there a better answer than Amazon's web services? (For those that don't know, Amazon provides hosting solutions that are API-driven, highly customizable, scalable, and billed-by-use.)

Google's solution is so simply by comparison that I am struggling to remember why this even matters to me. Something in my gut just keeps telling me it is wrong to rely on services where I can't understand the business model.

Also distracting from this actually-quite-cool service from Google is the fact that Yahoo! Pipes already offered this feature and many more. Additionally, I believe that Yahoo! doesn't require you to register for an API key against your URL, though there is a need to register to create a pipe (feed) if you aren't using one someone else already created.

P.S. If you are listening, sorry I'm not keeping up and haven't even uploaded the rest of my notes on my P2P collaboration presentation. I have lot's of activity at work these days keeping my creative energy going without having to resort to my blog rantings. :-) But, this was such a quick post.

Technorati Tags: google, yahoo, ajax, amazon

A CIO that "gets" open source and collaboration tools

2007-03-17T21:03:00.000-05:00

I've been really busy lately and will get back to the P2P Collaboration tool post soon. I've really been enjoying my new job and have been spending a bit too much time at it. :)

I was trying to catch up on a bit of my reading and I ran across a fantastic 50 minute video on open source in the enterprise when reading Stu's blog that I had to stop and share it really quickly. It is really worth the time. Be patient. If your job is related to information technology, you must hear this and consider it.

CIO JP Rangaswami breaks down the economic justification for using open source in the enterprise and many of the reasons we need to tear down the walled gardens. There are some specifics he gives for banks, but most technology companies will have very similar issues working with other companies. Any company taking an early stand for open source collaboration tools can gain the benefits of better recruiting as he explains. He also explains how the various tools are consolidating to standards and a small number of fundamental operations.

When I listen, it is more and more justification for the coming WebOS.

Again, the link is http://www.infoq.com/presentations/jp-rangaswami-open-source.

Peer-to-peer Collaboration Tools

2007-02-08T00:01:00.000-06:00

I gave this presentation at an internal company conference last week. Large corporations suffer from different collaboration issues than the open source world, but we also have much in common. My hope is to show folks at my company some tricks that we can learn from the open source world. Open source development is almost certain to be globally distributed and using on-line tools for almost all of the communication.

[Introduction]

It is rare that I get to speak about a topic for which I have such a great interest and I know will have such a great impact. The scale of the impact is on par with the emergence of e-mail as a technology. In fact, I don’t believe it will be very long before peer-to-peer-supported blog-like technology replaces e-mail as the primary communication mechanism over the Internet and corporate networks. Perhaps 3-5 years.

The title of my presentation is "overview of peer-to-peer collaboration technologies" and is sub-titled "managing communications with a global workforce". I chose this subtitle to emphasize that these technologies will help you address some of the many challenges of working in global teams. Communication is a fundamental problem of business that is complicated by globalization. I hope to show you here what is happening now to solve the communication requirements.

Purpose of this presentation
The purpose of this presentation is to illustrate that the emergence of peer-to-peer-based collaboration software is inevitable, show why [our company] should embrace peer-to-peer software architectures, and give an overview of some current peer-to-peer, metadata, and collaboration technologies. Some peer-to-peer collaboration architectures, such as Microsoft Office Groove 2007, will quickly and significantly alter the client-server architecture used for most existing content management systems, such as SharePoint, TWiki, and [our proprietary systems].

These peer-to-peer tools will allow the elimination of many IT dependencies. IT will obviously have significant roles to play, but those roles will change. With the emergence of these tools, team productivity can start almost immediately. Additional productivity and stability can then follow with more formalized IT involvement. For example, someone needs to create bridges between all the products and protocols. The various tools need to be combined into a single product with a consistent look and feel. The costs of deploying a collaboration solution can be optimized. Additional points of access and different accessibility features can be provided. My suggestion is that checkpoints requiring resource allocation, however, can be eliminated until there is a business benefit for IT involvement.

This isn't as much a choice I'm suggesting we make as it is the recognition that existing forces will drive acceptance of peer-to-peer related technology. On-the-go collaboration is a critical requirement of global business communication tools. Information locked into what can be called "walled gardens" or server silos cannot benefit all of the necessary people at the necessary times. This is certainly true in a global workforce of partnerships, third-parties, outsourcing, and ODMs. While business communications regulations, such as Sarbanes-Oxley and other E-Discovery requirements, will make the process more complex; they make it no less inevitable. The required technologies will survive by natural selection.

Tasks, e-mails, notes, and calendar items are mostly the same: they are a bit of collateral communication along with some specific metadata to allow the tool to know how to advise the user. There should be a tight association between the collateral, or content, or microcontent, and the metadata. These digital communications must be preserved in context. New metadata types, such as test case and product requirement associations, must also be supported. Making special tools to handle these bits of metadata is a formula for disaster.

The madness of creating new centralized walled gardens of highly specialized data repositories must be replaced with a vision of building new interoperable data definitions, widely accessible visualization tools, and improvements to existing communications infrastructure.

In this presentation, I will cover:

how I got interested in this problem,
why we need collaboration tools,
why collaboration will go peer-to-peer,
what a peer-to-peer collaboration tool might look like,
why should [our company] continue to evaluate peer-to-peer collaboration technologies, and
how you can get involved.

How did I get interested in this problem?
[Our company] entered the portable media player market in 1999. This market largely grew out of the popular usage of peer-to-peer file sharing applications, such as the old Napster. These peer-to-peer file sharing applications provided a source for content that established distributors weren't yet willing to provide. Learning about the architecture of these systems convinced me that they were useful for far more productive arenas than the sharing of pirated music.

The most critical aspect of making both peer-to-peer file sharing networks and portable media players work for people is the management of metadata. Metadata is the information associated to the content, such as the artist, title, genre, format, or rating. With all of the possible content available for download and playback, user satisfaction is driven by the ability to find desirable content quickly and easily using metadata. Apple's combination of the iPod scroll-wheel and the iTunes Music Store, along with a bit of slick advertising, gave people answers to where to get to music they wanted quickly. It led them to great success, without necessarily relying on peer-to-peer file swapping. Still, file swapping networks are still the quickest and easiest way to get to some content and they remain in wide use.

Failed attempts to defeat the networks convinced me that the technology will continue to be widely adopted, despite organized attempts to the contrary. The file swapping networks that are still in existence survived because they use peer-to-peer architectures. In a peer-to-peer application, there isn't a central server that can be shutdown to disable the network. Peers directly share metadata with each other, providing a path for sharing content. To build a peer-to-peer network, you only need peers speaking the same protocols and a willingness to participate.

The thing to remember here is that intelligent managing of metadata is how content is found, no matter what the platform.

Another experience I had was when this team went global. My job quickly shifted from a focus on media player technology to a focus on information management. I spent my time worrying about version control, status reports, bug tracking, requirements management, and portfolio management. The communication was less-than-efficient and the results were less-than-desired. This had nothing to do with the talent of the team, but had much to do with the communication mechanisms and processes that were in place. An 11 hour time-zone difference is literally one world away.

I saw that my experience in peer-to-peer technologies and metadata management could be applied to solve my new information management problems. Just like getting to media content quickly and easily helps media consumers, the product developers need quick and easy access to information.

Why do we need collaboration tools?
Communication in a global team cannot be handled entirely face-to-face. No matter how many worldwide face-to-face meetings you hold, when you break up and get back to work, there is always something left unsaid. Having frequent teleconferences helps close communication gaps, but they impact the work-flow of team members and never provide the depth of conversation required to establish a cohesive team.

While there is no substitute for strong individual communication skills, collaboration tools provide a path for competing with otherwise more convenient information sources and distractions. On-line tools provide opportunities for collaboration between people where distance, time, cultural, language, experience, and ability barriers exist.

You can see this in the success of open source projects like FireFox, which is a web browser that competes with Microsoft's Internet Explorer. Contributions to open source projects come from people all over the world in many different situations. To make open source projects work, the participants make extensive use of on-line collaboration tools.

Also note, the communication in these tools isn't one-way. The messages being communicated aren't dictates from a single expert telling everyone how to solve the problems of the whole. Requirements and solutions come from every member of the team and beyond.

Why will collaboration go peer-to-peer?
First, what do I mean by peer-to-peer? Back in 2001, Daniel Bricklin gave a speech at the O'Reilly P2P Conference on "The Cornucopia of the Commons". That speech was later printed in a great O'Reilly book. He quotes a 1968 essay on "The Tragedy of the Commons" summarizing a commonly expressed problem:

Therein is the tragedy. Each man is locked into a system that compels him to increase his herd without limit--in a world that is limited. Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons. Freedom in a commons brings ruin to all.

That isn't such a pleasant or welcome idea, but we can all see some degree of reality to that view.

Dan goes on to offer another view in the light of successful peer-to-peer architectures and their failings:

In the case of certain ingeniously planned services, we find a contrasting cornucopia of the commons: use brings overflowing abundance. Peer-to-peer architectures and technologies may have their benefits, but I think the historical lesson is clear: concentrate on what you can get from users, and use whatever protocol can maximize their voluntary contributions. That seems to be where the greatest promise lies for the new kinds of collaborative environments.

That is the thinking that launched the Web 2.0 explosion with businesses like Flickr, MySpace, and YouTube. Similarly, when I'm referring to peer-to-peer technologies, I'm talking about creating protocols that maximize the contributions from the edges. Those contributions generate a wealth of information and content highly valued by users.

The elimination of a required centralized server is one common technology applied in peer-to-peer architectures. The benefits that approach provides to IT may be a bit counter-intuitive. I've done a small amount of examination of four benefit areas to collaboration tools by elimination of a required centralized server: security, reliability, interactivity, and efficiency.

The elimination of a centralized server is sometimes required for security purposes. We occasionally enter contracts with other corporations that give very explicit rules about who can have certain data on their hard drives. A centralized server would violate that policy, whereas it may still be acceptable to share the data with specific peers. Ultimately, security is best provided if information managers control the access to data, rather than IT.

There is also the occasional need to utilize modern tools that aren't yet available on our internal servers. Some of those tools are available on external servers, but it isn't secure to place [our company's] private data on those servers. A tool that does not rely on a centralized server could be more easily deployed. This doesn't eliminate the need for security audits on the tool, but it does eliminate the overhead of evaluating the impact of that tool on other tools running on a common server.

Despite on-going improvements to server reliability, there doesn't ever seem to be an end to the reasons why a server must occasionally be shutdown or relocated. With an architecture that doesn't rely on a single centralized server, the reliability is certain to be increased. An application network that requires a high degree of reliability should still make use of high-reliability servers, but it makes sense to architect those networks to not rely on them exclusively when possible.

Efficiency benefits from eliminating requirements on a central server come from the ability to rapidly deploy a new peer-to-peer network. A business could deploy a new network right away to gain the benefits of collaboration without waiting for a high-reliability server to come on-line. Such a server could then later be deployed to increase the reliability of the network without creating downtime. Further, an information manager within the business can be directly responsible for adding and removing users, machines, and services on the network.

Efficiency benefits also come from more general aspects of peer-to-peer architecture. By allowing users to organize their own data, they can access it more efficiently. In most cases, there isn't one ideal solution to data organization. A peer-to-peer architecture allows everyone to organize their own data and allow others to benefit from that organization.

By interactivity, I mean both the possibility of working with other tools and the way the tool works for its users. Interoperability and connectivity to other tools doesn't necessarily require the elimination of a central server, but tools that don't attempt to create a centralized repository for information are more likely to support the standards required for interoperability. By creating protocols for use in a peer-to-peer network, some of the requirements for interacting with other tools are necessarily met.

One particular interactivity benefit of eliminating requirements on a central server is the possibility of providing "on-the-go" or disconnected collaboration. You experience this today with Outlook when you are on a plane. You can read your e-mail that is cached locally, create your responses off-line, and synchronize your mail once you are connected to the network again.

E-mail must be the most common on-line tool for collaboration. It is simple, universal, "on-the-go", search-able, you know who is on both ends, you get notification, and for the most part it just works.

Being such an effective collaboration tool, e-mail has many peer-to-peer architecture characteristics. Foremost, it is distributed and resilient. It relies on DNS, the domain name service that is used to look-up the address of servers on the Internet. DNS is distributed and resilient, allowing for server failures at many points in the system. Further, SMTP, the protocol used to forward e-mail messages, can be run on just about any computer. You could almost decide to run SMTP on your own desktop machine, but you'd quickly find that getting the DNS record to point to your machine is a bit of a hassle when you don't leave your machine running all of the time. This doesn't matter that much, though, since [our company] provides you with a high-reliability server to collect your e-mail and clients that cache the e-mail for off-line use.

So, what is wrong with e-mail as a collaboration tool? First of all, the information is trapped into little personal "silos" that no one else on your team can search or access. Certainly you don't want to share all of the information provided to you by e-mail, but some of it you do. Some of it you just want other people to know you have, but not necessarily give it to them without your approval. You can forward e-mail to individuals or mailing lists. You can archive e-mail sent to mailing lists on a website. You can even create shared mailboxes, though those are a bit complex for many people to handle. In the end, you are left with a large number of small silos of data that can't be organized as part of a larger body of information.

E-mail is not secure. Sure, there are tools for encrypting e-mail, but they are practically only ever used on the most sensitive data. E-mail encryption tools are simply too difficult to use and you cannot yet create encrypted messages for the vast majority of your e-mail address book and expect the recipients to be able to perform the decryption.

Monitoring e-mail for sensitive data is virtually impossible. E-mail is sent from all levels of the organization all across the world, without any approval of information managers. When inappropriate e-mail is detected, there is no realistic mechanism for confirming retraction of that data from recipients. Outlook has a "recall" feature, but it often fails and cannot be confirmed outside of our organization. E-mail must be the most important and most dangerous of all the collaboration tools available today.

Perhaps the worst aspect of e-mail is the lack of efficiency. Information coming in e-mails cannot be easily categorized. Creation of e-mail filters often makes the situation worse by creating yet more silos of data. Fields that would allow for some categorization, such as priority, action required flags, and deadlines, are typically never used and are often misused. Misuse is sometimes the result of spam, which is a problem that cannot easily be avoided. By one study, 94% of e-mail last month was spam.

What about TWiki or SharePoint? These tools are often called "content management systems". They can be quite effective in improving communication within a global team, but they have their own issues. Perhaps the best summary comes from a success story taken from the TWiki website from a company that deployed TWiki to improve support to field engineers:

People in the field were used to using email for communicating with the factory. Email is a one to one communication, a mailing list a one to many. The problem with email is that useful information does not reach everybody, email is not easy to search and email gets lost over time. Collaborating the Wiki way solves these problems, however changing habits is a difficult issue that needed to be coached.

Initially we also had a chicken-and-egg problem, i.e. voices like "why should I use this collaboration tool, the content is so limited". The solution was to assign a support engineer who monitored the mailing lists and entered useful information into TWiki.

Successful deployment took over 6 month[s], [which was] longer [than] expected. But now everybody is used to browse, search, collaborate and document the Wiki way.

The result was that customer satisfaction with the field support improved. The effort was a real success.

This sort of dedicated information management may not be something we can easily commit in our environment. If deployment took 6 months, how are we supposed to keep up with frequent release cycles? How do we convince managers to commit resources to TWiki when current searches for me today often return my own weekly reports, rather than something of valuable interest? With so little attention, even the top-level structure of the TWiki sites today can't even keep up with our organizational structure. I believe in TWiki, but we can only overcome this "chicken-and-egg" problem in each team by strongly evangelizing its use during the painful learning stages.

SharePoint has similar problems, but is a bit of a different beast. SharePoint is particularly well-suited for collaborating on Microsoft Office documents. It uses a standard protocol called WebDAV that allows for folder views in Windows Explorer. Most importantly, [our company] supports a mechanism for accessing SharePoint sites to customers and partners from outside the firewall.

The biggest problem with SharePoint, beyond the problems it shares with TWiki, is its complexity. The user permissions tables are extremely convoluted. Editing the content of any one page requires extensive knowledge of the overall system, rather than simply clicking an "edit" button and changing some text. I’m not saying that TWiki markup is trivial, but it doesn’t require learning specialized tools or extensive training. The help system is built right into the tool. Also, the SharePoint version control system is somewhat less than reliable because it allows overwriting and elimination of old document revisions.

We are still learning about how best to use TWiki and SharePoint on our projects and the best standard practices are not obvious with either tool. Neither provides great search solutions for the data you need on their own, especially if the data is in mixed formats. Instead of providing a complete knowledge picture, the combined usage of e-mail, TWiki, and SharePoint creates islands of information that must each be explored separately.

[Description of an internal collaboration tool]

Efforts like this should continue, but it is best to break up the platform into interoperable components. Consider interaction with a tool such as Microsoft Live Clipboard. Live Clipboard is a mechanism for users to initiate sharing of data between websites without requiring development of web services scripts or other complicated programming. By supporting such a feature in all of our collaboration tools, the islands of information can be bridged.

The same guy at Microsoft who dreamed up Live Clipboard, Ray Ozzie, has also brought us one of the more compelling peer-to-peer collaboration tools already available, Microsoft Office Groove 2007. Recently we made use of Groove on one of our projects. The project spanned two partner companies and two contractors. Some folks on the team were able to start collaborating on the very first day by simply installing the tool. It took a few more days for others to overcome some minor installation headaches that were likely related to the tool being in beta. The product will be released with the 2007 version of Microsoft Office.

Groove works across firewalls, provides account management, secures communications, provides synchronization for off-line usage, includes instant messaging with some voice capability, and has some limited integration with Office applications and SharePoint. When I talk about the integration being limited, however, it needs some emphasis. All of your important e-mail, calendar, and contact information isn't easily shared in Groove with something as simple as a single click on a category. To get that information into Groove, a user must jump through many hoops. A major concern for the team was lack of support for maintaining old versions of documents. Groove did a great job of ensuring everyone had a copy of the latest version of a document, but SharePoint was required to maintain historical copies.

Groove also lacks a client for any platform besides Windows and the client can be a bit slow because it consumes a large amount of memory at times. There is no way to see the data in Groove by simply logging into a web page. You can synchronize a SharePoint with Groove, but it is a tool separate from the other tools in Groove which all seem to act as more islands unto themselves.

Ultimately, usage of Groove suffers for many of the same reasons as the web-based content management tools. Some folks wouldn't use it regularly, instead using familiar tools such as e-mail. It never became part of the team's everyday work flow, partially because other tools were required to author rich documents and manage code. The client tool was seen as painful to start-up or leave running. Ultimately, nothing was pushing users to actively communicate using Groove.

Certainly there are some dangers with this going unchecked, primarily related to it being difficult for IT to log file exchanges. Exchanges over SSL secured websites or, to a lesser degree, encrypted e-mails offer similar challenges. Ultimately, there are always ways for employees to circumvent security and, in some cases, the risk of not progressing business is worse than the risk of compromising security.

What might a peer-to-peer collaboration tool look like?
Groove offers a good starting point for describing the peer-to-peer collaboration tools of the future, but it is not alone in its class. What I'd like now is to describe for you some of the building blocks for creating a tool like Groove and some of the building blocks that could be used to make a better tool. I won't draw you a complete picture of the ideal peer-to-peer collaboration tool, but I hope to point you in that direction.

I'll finish typing this up when I get back from vacation next week. I need to scrub and upload the pictures...

Ending walled gardens with microformatted microcontent

2007-02-07T01:00:00.000-06:00

Forgive me for stating the obvious today, but I'm surprised how little I seem to see this point repeated.

I continue to be surprised by the continual emergence of Web 2.0 companies putting up walled gardens to try to hold onto users. I think MySpace is the current prototypical example. They could use a lesson from AOL on how likely they are to be successful over the long term. When AOL offered ease-of-use, content, and community features that simply weren't available on the Internet at the time, AOL grew at enormous rates. Once the Internet was well established outside of AOL's walls, AOL quickly tumbled.

You can expect the same results with MySpace. From outside MySpace today, it is possible to link to MySpace, be linked by MySpace pages, and consume MySpace blog entries using an RSS feed. Interaction to the broader Internet is roughly limited to just those features. Once there is broader access to video/photo/blog/music hosting, friend linking, trusted commenting, shared calendars, templates/widgets, and all of the other MySpace features, people will start wondering why they put up with all of the advertising and spam on MySpace. MySpace is "free", but there are many degrees of freedom. Person A might even want to control how Person B's sites appear when Person A reads them. This freedom is established with microformatted microcontent over RSS/Atom feeds and aggregated feed readers.

Microcontent is simply each of the entries you make on your MySpace pages (or other people's pages) today, but placed into small, consistent containers. Your preferences could be stored in a microcontent article. Certainly each of your blog entries, friend relationships, and everything else you communicate on MySpace could also be placed into microcontent articles once the right microformats are defined. Those microformats provide the protocol for interoperability in whatever RSS reader you use.

Of course, the RSS readers need to be smarter than they are today. Bloglines and Google Reader are fantastic compared to what we had before they existed. They are, however, still significantly limited, providing almost no microformat or customization support at all. This will change quickly, however, and the garden walls of social networking will fall before people start trying to build walls around something totally new.

So, Web 2.0 companies, I guess you can't help but build your pretty little walled gardens while you can. If I was a VC, I wouldn't give you a dime unless you had an exit plan.

Are You Paying Attention?: Announcing the Media 2.0 Workgroup

2007-01-29T21:05:00.000-06:00

Are You Paying Attention?: Announcing the Media 2.0 Workgroup: "trackback"

Is the WebOS revolution over?

2007-01-19T13:22:00.000-06:00

Muli Koppel wrote a nice piece on why the web2.0 revolution has failed. By the same measure, I believe we'd need to conclude that the WebOS revolution, which hasn't even taken off yet, has also failed. Before a real WebOS could even be created to provide the people with a viable web development environment, the term has acted as a gravity point for commercially-minded folks trying to capture hold of people's valuable data. (Correction: Thanks Benjamin) At least the Exo Platform gives you the server code ~~, but the release I've played with doesn't give all of the source~~ and is available under GPL license. EyeOS is also open source and includes a "mini-server" that provides LAMP-like support on your PC, though a database is not required.

Muli's examples of "failed" revolutions, punk, open source, and Second Life, do give room for hope. Each has failed to reach their ideals, but each has also made improvements to our culture along the paths of those ideals.

Perhaps the real revolution is still in the works. Maybe the only way to succeed is to avoid naming the revolution completely until it is already won. Besides, no one has offered me any useful names for the product that will ultimately emerge.

Update (Jan 20): Keep the feedback coming. Let me know why you think the WebOS revolution is on!

Poisoning the WebOS well

2007-01-12T09:41:00.000-06:00

The term 'WebOS', or web operating system, has been useful to gain attention to the idea of creating a framework for rapid web application development and making those applications available from any computer with a web browser and Internet access. This is a noble and important goal. Making web applications can otherwise be quite difficult. We should take advantage of the web to simplify creation, distribution, and interaction of our applications.

The windowing glitz of the current so-called WebOS offerings has bloggers questioning the point. Windows within windows just seem silly. They solve a problem of maintaining the state of an entire collection of applications in an environment, but they they recreate a paradigm that users where there is already a significant amount of frustration: the desktop. I'm not ruling out the possibility of using this paradigm, but it distracts from the more fundamental problems of rapid application development and distributed access.

It would be great if this web-based desktop-like, or webtop, functionality could be isolated from the rest of the WebOS discussion. As long as these webtop offerings are being called WebOSes, as long as they are being reviewed only on their webtop merits, the WebOS well will continue to be poisoned. There really isn't much that can be done in the short term. Eventually, some new terminology will emerge to differentiate web application frameworks that provide glitzy windowing and ones that allow the rich array of web services to be used easily and transparently by even the most novice of developers. Sometimes they might be the same framework.

Read more on this blog about what a WebOS could be, then tell me what I should be calling this sort of web application development framework.

Droolling over the Apple iPhone

2007-01-09T14:45:00.000-06:00

The inclusion of OS X, full-blown Safari, and 802.11 support has got me. Finally, *nix in a widely available US phone. I wish it had EVDO in addition to EDGE, so it will be slow compared to my Treo 700p. Quad-band GSM--nice, should be a good international phone.

Anyone know if it will support A2DP so I can use my stereo Bluetooth headphones?

Update: It looks like it does according to Engadget.

New microformat, not viagra

2007-01-04T10:40:00.000-06:00

Posting comments on blogs is still a pain. I just tried to post the following comment to a post on APIs being the next site map:

I agree with you, APIs are the new site map. [comment about site rejecting previous post]

There is still extensive work to be done to eliminate the silos. First, everyone has to have their own web server. The technology isn't really there for that today, unless you count projects like Paper Airplane (which isn't a complete product). Next, service providers need to provide a common set of services that will allow everyone the freedom to move from their limited function server onto the full-scale Internet.

I call that common set of services a WebOS API (http://clamoring.blogspot.com/2006/12/defining-webos-api.html). A new name is probably needed, since folks seem to have stolen that name for webtops.
Do you think a microformat that describes that site map and API would be useful? It would need to replace something machine oriented that is already useful today, such as WSDL.

The following response was given:

Comment Posting Guidelines
Sorry but it looks as though your comment has been filtered out to avoid blog spam. You weren't trying to sell me viagra were you?

Does that look like a viagra advertisement to you? Oh well, I understand the need for comment filters. It would have been nice if it at least indicated that it was going into a moderation queue.

Selling out

2007-01-04T07:46:00.000-06:00

I've added Google AdSense to my site. This site is largely an experiment for me to best understand the technology of blogging, so I'm really not in it for the money. If the ads bother you, just let me know and I'll remove them.

The Snap previews are there to help you get an idea what is being linked, but they can be annoying at times as well. Please give me your feedback on those too.

Also, note that there are now 4 feeds on this site. The original two from Blogger and two from FeedBurner. The main Feedburner link adds my del.icio.us and Flickr posts. The other Feedburner link is just to my Google Reader shared items.

Step #1 to Creating a WebOS: Proxy Server

2007-01-03T07:44:00.000-06:00

Reading blogs this morning, I ran across Brad Neuberg's announcement that he is working for SitePen to create an off-line Dojo toolkit. I have to get ready for my day job now, but I'm excited enough that had to write something first. This is really step #1 to creating a WebOS.

I've mentioned in the past how a client-side server is required to create a proper WebOS. That seems to be exactly the approach Brad is taking.

An off-the-shelf, open source (GPL), C-based web-proxy will be used, named Polipo, saving months of development time creating a custom HTTP/1.1 proxy.

Deploying with a C-based solution seems like the wrong idea to me. I've toyed with something similar using Java and JavaScript to create a thin web server/proxy. I haven't been able to dedicate enough time to get it to the point I can demonstrate it. Keeping Dojo almost entirely in JavaScript, and using Java server implementations like Tomcat or Jetty, would seem more portable and supportable.

I also commented to Brad that Scrybe seems to do the off-line work without a proxy, though they may just be leaving that out of the demo information.

The great news, however, is that Dojo is a really popular open source toolkit and should get a lot of traction, even if it isn't on as many platforms as possible from the start. Brad also seems to be a really smart guy.

Increasing traffic randomly

2007-01-02T16:29:00.000-06:00

I was reading Mike-O-Matic and ran across his Click Pyramid site.

This is how it works:

You visiting each link below in turn and collect the codes that are presented.
These codes are entered into the form below, along with the website information you would like added to our database.
You are then given a link to a new list, which will have your site first on the list and each one moved down one slot. The bottom site will drop off.
You can then place that link in web advertisements or on your website/blog. Any users who click on it will go through a similar process to add their link, and will spread your link even further.

I figured it couldn't do any harm, so I created my own ID, #208. Only 208! Oh well, I guess I'm spreading good karma for someone who created a couple of blog entries that I found interesting.

Of course, if I advertise that link, wouldn't I just be better off advertising my own site instead of adding it to a list with 4 other sites? I guess that I could get a few people to check out my site simply because they want to advertise theirs, but doesn't allowing them to leave a comment on my blog accomplish roughly the same thing?

The thought is still somewhat interesting, but someone will have to turn it around somehow to make it work.

WebOS killer app

2007-01-01T10:31:00.000-06:00

The VC guys are saying a WebOS or Browser OS is on the way, but web developers are asking what will be the killer app to bring about a standard? I think we've already seen "alphas" of the killer app in MySpace, Facebook, YouTube, etc.. Privacy, interoperability, ease-of-use, and desktop-integration will drive standardization of those services, starting in the open source community.

Google: left hand meet right hand

2006-12-31T10:44:00.000-06:00

This is a very common problem in the software industry, so I won't pick on Google too hard. My last post about Google's Firefox extensions didn't get any responses, so I thought I'd spend a couple minutes to find out if Google already had plans to fix the problem.

I found the announcement of the extension made by Glen Murphy about a year ago, but didn't find any follow-up announcements on that blog by Glen.

I checked the FAQ, nothing too useful there. There were support contacts; an e-mail address and a discussion group. The discussion group had relevant information:

If you just signed up for Blogger, you've got a Blogger Beta account. Google hasn't yet updated their extensions to be compatible with Blogger Beta. Once they do,
you'll be able to do whatever you should be able to do with the
extension. Until then, I'm sorry to say you're stuck with the Web
interface. :(

My complaint is that Blogger is no longer in beta. There is no mention of this issue on the Blogger bug list, at least that I could find. Before you take something out of beta, shouldn't you make sure the other products from your company actually work with it?

Well, I'm hopeful that Google has already figured out this is a problem and that is why they are talking about more features and fewer products. See interview and Time article.

Google Blogger Web Comments Firefox extension is broken

2006-12-29T17:18:00.001-06:00

I decided I would play with some more Firefox plugins useful for bloggers and found a pretty nice one from Google, where this blog is hosted. The plugin adds comments to websites by looking for blog entries that link to that URL. This is pretty cool and works fairly well, but when I tried to create a comment (blog entry) using the extension, I got a login error. I use the new version of Blogger, so that could be the issue. I guess Google has the same problems as all of the other large companies when it comes to having one group talk to another.

If they use their own tools, I'd expect them to find this post quickly and fix their extension!

technorati tags:google, firefox, extension, blogger

Blogged with Flock

Quick note on the prematurely declared death of XML

2006-12-28T22:53:00.000-06:00

I was initially taken aback when I read Douglas Crockford's blog post from a couple weeks ago titled "XML on the Web is Dead". He starts:

At the XML2006 conference in Boston last week, I heard a number of people proclaim that XML on the web is dead. XHTML is not going to replace HTML as the web's official markup language because it turns out that resilience is more useful than brittleness. And JSON is quickly displacing XML as the preferred encoding for data interchange.

I agree with the attack on XML for data interchange. What is required for data interchange is something that works and works easily. The data is consumed in JavaScript and JSON also solves the nasty little sandbox problem, so it works. No argument from me there.

As far as markup, well, this jostled me a bit more. Sure, a parser that expects only well-formed XHTML will be brittle, but that is no reason not to generate well-formed XHTML source. XHTML adds value to developers by providing namespaces and better character encoding support, right? When the XHTML is well-formed, the parsing can be done quite small and fast. When it is not well-formed, the tag soup can still generally be handled by the browser parser with some extra work. That may go against the (misguided?) aspirations for a parser that would reject such bad XHTML, but it faces the realities of compatibility in computing platforms.

When I mention namespaces as a feature here, I'm not considering it a great feature that some folks come up with XML schemas that the web browser doesn't know. I'm talking aboug SVG, MathML, and other schemas known to the browser. I hope I'm not in the minority thinking these are useful for many web developers.

Douglas went on to group the reactions of folks at the conference into three categories.

The third was "Don't say it like that." XML is in decline on the browser, but it still has a role on the server. If we go around saying it's dead, people might start looking for better alternatives.

Well, life would be boring if we weren't always looking for better alternatives. The point that browser-side programmers are looking for easier ways to exchange data, seems quite valid and I think the choice of JSON is exactly right. I think it is time for JavaScript to get some more serious usage on the server-side and there is lots to talk about there. Maybe calling XML-on-the-web dead isn't that bad a thing to say.

XML and RDF haven't delivered all the tools necessary to turn everyday web programmers into clerics of the Semantic Web. They have delivered enough to be useful, living components on the web, even if they aren't given those names. I'm curious to know if anyone has done a good study of XHTML usage as Google did for HTML usage last year. I'd still expect to find its use frequent and growing.

Blogging with Flock

2006-12-26T23:48:00.001-06:00

I'm a bit of a nervous person. When Flock asks me for all of the usernames and passwords for my various social networking tools, it doesn't make me comfortable. Since this blog is about web-based collaboration, trying out some of the newer tools would seem to be a requirement. Now that Blogger is no longer in beta and is supported by Flock, it seemed appropriate to hit the "Blog" button on the first article I saw:

What Blogging Platforms Does Flock Support?
A table of supported blogging platforms is detailed at: http://wiki.flock.com/index.php?title=Blog_compatibility.

This is my second attempt to create this post. The first one was eaten when Flock crashed.

technorati tags:blogging, flock, collaboration, tools

Blogged with Flock

Characteristics of the winning WebOS

2006-12-26T22:16:00.000-06:00

I'm going to predict the future for you here. Hopefully, like any good prognosticator, I'll leave my definitions vague enough and my time-line open enough that I'm almost guaranteed to be correct. What I'm going to tell you is the look of the web operating system, or WOS, that will ultimately "win".

The primary purpose of a WOS is to convert web services into a commodity. This is really just argument by assertion, but here goes anyway.

DOS is to disk as WOS is to ___?
The point of a computer operating system is to abstract all of the "interesting" parts of a computer in a way that allows application programmers to make use of them. Think back. Disk Operating System, or DOS, existed to read applications off of disks and to allow those applications to read and write to disks. Without a disk operating system, application providers would need to partner up with both computer and disk drive providers to deliver an application suite. Some amount of application code would need to exist in the ROM of the computer just to read the rest of the application suite off the disk.

This is largely the state of the web today. A complete web application utilizes a wide variety of web services for distribution, authentication, session management, search, etc. To deliver a web application today, you need to deliver an entire web server, or fleet of web servers. You can partner with other businesses for site hosting, back-end databases, and storage. You can utilize relatively common components, such as with LAMP. Nevertheless, as it stands, it is impossible to define a complete and relatively complex web application that can be freely moved from one operating environment to another.

Many of the critical services needed by a web application can be hosted by the local desktop. I argue a WOS must include a reference server, though I don't know if that is the only solution. What I do know is that one desktop server doesn't scale well to applications that could have users across the entire web. It is therefore critical the application just as easily makes use of commodity web services. That is the benefit of using a WOS. It provides the abstraction to make an web application that can scale without modification.

The interactions we can have with the web are much more interesting than the interactions we can have with disks, but I think the analogy holds. There are even some important interactions with disks that current desktop operating systems don't support, but that is a another story. I even go so far as to say that using a WOS should allow you move your applications to an entirely different web, off of the Internet and onto a private LAN. It is only some subset of the web that can be truly abstracted in this way and many web applications will have dependencies that don't allow them to work independent of the Internet.

That subset of services that can be made independent of the Internet is what is important to a WOS.

Growing the market for web services
I don't mean to say that a WOS developer should focus only on the server-side. A WOS must provide an environment where those web services can be consumed by a sufficiently large market. In this context, it can be critically important to provide a rich set of client services and template applications to simplify application development. Some people seem to get this secondary objective of a WOS confused, such as the blogger quoted below.

But what is a WebOS (not to be confused with another definition of the term, see here), or a Webtop, anyway ? Here’s a simple definition: WebOS is a virtual operating system that runs in your web browser. More precisely, it’s a set of applications running in a web browser that together mimic, replace or largely supplement a desktop OS environment.

The "webtop" functionality is important in the simplicity it provides in creating web application, but I think Wikipedia's definition is closer to correct. I struggle, however, to see where a webtop alone will significantly help generate the next killer web application. Web browsers already support tabbing and there are plenty of AJAX frameworks for producing rich interfaces. While a webtop and set of example applications seems necessary to be recognized as a WebOS, do any of these webtops offer sufficient benefit to application developers to lock themselves into one of them?

How a WOS will generate cash
Consumers want everything to be free. That is, they want it to cost them so little effort or resource that they don't even know they are paying. This is where a WOS has some real potential. A WOS can turn all of those profitless web application companies into differentiated web service providers. How?--by putting a line between what is scarce and what is abundant.

Software is abundant. Given enough time, someone is going to write this WOS of the future and make it open source, so there is little hope of making money off of selling one in the long term. Though there is little money-making potential for someone making just the software for a WOS, there is significant value for the service, content, and hardware providers. The existence of a WOS can increase the number of their consumers and provide the infrastructure they need for revenue, such as micropayments. The most successful WOS will turn the scarce service and content resources into commodities, maximizing their availability.

At first, nervous service and content providers may be reluctant to feed such an ecosystem where they are on level ground with their competitors. They will wonder if they will be able to sustain their value. Eventually, they will learn that there is still value in their brand, their services, and their content. Why? Brands are scarce, because attention is finite and it takes attention to build confidence. Services require resources and expertise, and are therefore scarce. Despite the seeming abundance of user-generated content and the high-availability of copies of any particular content, there is a finite amount of content available to sustain the value of any given brand. Though new markets can be generated on top of an existing consumer base, the ability to generate content that is suitable to an existing target market is limited to a finite set of content providers. In other words, people will get bored watching home videos of cats climbing the curtains.

With the scarcity of services and content, the abundant WOS will simply be the catalyst for revenue. The hardware is a story for another day.

The predictions
To conclude, here are the top 10 characteristics I see for the winning WOS:

It will be a standard, not a single implementation.
It will be implemented with open source software at least once.
It will be packaged with a web browser, like Flock.
It will make transparent use of free (community-based), fee-based, subscription-based, or advertising-based web services when local services aren't sufficient.
It will make use of open identity services, like OpenID.
It will provide namespace and tunneling services, like Paper Airplane.
It will provide media playback, publishing, and subscription services, like Democracy and Broadcast Machine.
It will work on any network, including a network of a single computer.
It will be accessible, isolating the application presentation such that the interface can be implemented independent from the core application.
It will provide bandwidth aggregation, like BitTorrent.

(Update Jan 6: link to my other posts on web operating systems)

Pimp my blog with FeedFlare

2006-12-21T14:27:00.000-06:00

I'm not one of those people that is obsessed about having my own unique CSS, so you won't see me waste much time with that. As long as the format is readable and the HTML in the post feed looks okay, I'm happy.

What does interest me is finding people who get something out of my posts. I have a grand vision for the web, as many other people more influential than me do as well. My first few entries have been a bit longer than I'd like, but they are such a small step towards sharing my vision. It has been a challenge to keep them even as short as they are. Of course, having a day job helps. Nevertheless, I've noticed that a few people have managed to discover and read these entries. I'm hopeful that I'll be able to participate in discussions on these shared interests in the future.

Quickly catching myself up with some of the recent blogging tools, I found a couple of interesting posts. One was from Robert Scoble with a great interview with Google's Marc Lucovsky talking about adding AJAX Search to your blog. I could use that to tie in other blogs talking about the same topics. The idea is to make it easier for someone, mostly me, to participate on a certain range of ideas. Well, that isn't going to be trivial, so I will move on for now.

The other post was from Matt McAlister on a new Del.icio.us publisher API. I'm a Del.icio.us user who scans for other people that bookmark items like I do. I add those people to my network. Putting the information of how many people bookmark my posts directly on my blog will save me some cycles. The first place I found information on the API was on FeedBurner, where they have added use of the API to their FeedFlare service.

I created a FeedBurner feed for my blog. The next step was to add the FeedFlare to my blog itself. One blogger pointed out that FeedBurner provides you with information that doesn't go with Blogger Beta. Followed the advice, I went to the FeedBurner forums to pick up the required snippet.

Simple enough for me. Actually, it was pretty darn simple. Sure, I've left out all of the issues of now having multiple feeds, so I'll never be able to tell just how many subscribers I have. Sure, I've given my e-mail address to half the Earth by now to get access to one web service after another. No, I don't have any guarantees those guys will be providing that same service to me tomorrow, but why shouldn't they? Should I really be expecting anything more?

(Update 2006-12-23: I saw today Del.icio.us posted information on their site about the new API. I probably won't look at it much, since I've already got it going with FeedFlare.)

Defining a WebOS API

2006-12-19T16:00:00.000-06:00

It has been a couple of years since everyone came around to realize that the web is the most important emerging application platform. All hands are now on-deck to fight the resulting API war. Because I am an embedded software developer, you might think I wouldn't have much of a role to play in this war. I hope you'd be wrong.

What might seem simpler to some might be harder to understand for others
Back in the day when computers were hard to use, many of the non-engineers that I know would make use of computers by writing small programs. Those programs might print their names across the screen or play sequences of musical notes. On occasion, those programs would be borrowed from a magazine and might encompass an entire adventure or arcade game. I wouldn't necessarily call this programming, but it meant that they understood how to edit a source file, invoke the compiler or interpreter, and run an application they could actually dissect themselves. How many of your friends not involved in writing software for a living can do this today?

Those were also days when people made backups of their floppy disks. Sure, part of that was because they had personal experience with data loss, but they also would lose smaller bits of data at a time to learn this lesson. What's more, their computers would still work without any time lost to restore a backup to a hard drive. How many of your computer using friends create a backup of their data today, let alone a bootable image with the programs required for using that data?

See also:
Microsoft BASIC Wikipedia entry
TRS-80 Model I Level II BASIC page

Don't get me wrong, I dread the idea of turning on my computer and seeing a BASIC "Ready" prompt looking back at me. I hope you'll admit, if not reminisce, that prompt let you at least know what state your computer was in and what it was "Ready" to do. The really good news is web browsers have given much of that know-what-state information back to computer users through the beauty of a hyperlink or URL. Typing a URL into the address bar of your favorite browser typically results in something you expect.

Since running web applications is easy, programming them should be easy too. If we can stay a little focussed, we might just find that is possible.

What is an API?
In the embedded world, I get pretty frustrated with how often a function call is confused with an API. I can accept that a collection of function call definitions could constitute an API, but a good API is often much more than that. An API is everything an application programmer requires to make use of a bundle of software that was created by someone else. So, a documented set of function calls into a library could be an API, but so could documented interrupt traps, messages, or even URLs. What is important is that you can give enough information to the application programmer to make use of your software bundle.

In the web application and web services worlds, there are lots of possible starting points for defining an API, all with various benefits and pitfalls. On the web services side, there are SOAP, XML-RPC, and many more. On the web application client side, there are Mochikit, Dojo, DOM, GWT, and many more. On the web application server side, there are Zope, Zend, Ruby on Rails, Mediawiki, Twiki, SharePoint, Blogger, Drupal, and many, many more. Gather it up and there is a lot of room for confusion.

Fortunately, as complicated as all of the support layers have gotten, the fundamentals of how most of the web works have remained relatively consistent. Data is fetched from URLs using HTTP's GET method and manipulated using two or three other HTTP methods. This thinking has been captured in the representational state transfer architectural style, or REST, as described by Roy Fielding's doctoral dissertation. Given average computer user's familiarity with fetching data using URLs and providing input using on-line forms, there is some potential for creating an API that people can understand.

A web service or web operating system REST API is somewhat akin to a desktop operating system call or software trap. In a system call, the application prepares some aspects of the CPU state then executes a CPU instruction to enter a more privileged set of code defined by the operating system. It is an important feature to not make these calls transparent, because this is where potentially sensitive information is moved to the network. These HTTP transactions are abstracted network transactions that most computer users can understand, because they already make these transactions frequently.

An early entry
YouOS has created something of an API for applications running within their WebOS environment. This API includes web application client library functions and server functions. YouOS has communicated their goals in the YouOS manifesto.

YouOS strives to bring the web and traditional operating systems together to form a shared virtual computer. To you, it's one giant computer that you and your friends can work on. To us, it's all the servers, routers, software, bandwidth, and engineers to keep this grand experiment in collaborative computing running.

I agree this is a noble vision for a web operating system, but this isn't necessarily in the best interest of consumers. At the least, some off-line capability, such as that described for Scrybe, should be included. Ultimately, there is also little reason to pay for storage and bandwidth if your home ISP connection is sufficient. I love the Amazon web services that YouOS utilizes to provide the scalability for Internet-wide software deployments, but locking customers into a single source provider for YouFS isn't in a consumer's best interest. Big players won't see a reason to use the service defined by YouOS because they can invest in their own infrastructure and new developers can't start small enough, which is confined to their desktop.

Provide an open source server implementation and client library
One answer is to provide an implementation of the server that is hosted locally. By continuing to use the HTTP interface definition, the location of the service, primarily data storage and retrieval, can instantly be made irrelevant. Further, it defines the necessary interface for authentication and provides a sandbox for web applications. A new developer who learns this environment can be given most of the lessons necessary to deploy their application across the Internet.

A pitfall that must be avoided is the creation of too many abstractions in the client library that are potentially more leaky than the HTTP interface. The programmer should be kept aware of the HTTP transactions that need to occur to perform their desired tasks. By providing a local server, significant services can be kept out of the client library.

I'm not saying that the client library should be avoided all together, but it shouldn't be seen as the entry to the operating system. The client library is more akin to libc for C programs or the standard template library for C++ programs, but with less need for portability. As long as a web application makes only the HTTP transactions supported by the web operating system, it should run just fine, no matter what language or client library is used.

Use microformatted XHTML, not a new XML schema
What shouldn't be avoided is defining the inputs and outputs of those HTTP transactions to be extensible, forwards compatible, and backwards compatible. A simple approach to this is to make use of microformatted XHTML for all queries and results. The server should still support HTML for robustness, but only generate XHTML. XHTML is something that every major web browser already knows how to parse and present. Microformats extend XHTML in a way that doesn't break that compatibility.

One huge lift from using microformatted XHTML is the ability to provide a service like Amazon's AWS Zone directly on-top of the web operating system services, without needing to understand the syntax of WSDL and SOAP. This self-documenting style is exactly what is necessary for those new to programming. This allows for cut-and-paste style experimentation to produce results that can be expected, such as how many people initially learned to produce HTML documents.

What all should a WebOS do?
Certainly it should provide data management so that you can get to your data wherever you are. I'd say it should go a bit further and define the paradigms for protecting and sharing that data with other users. Sharing content, especially media, is an area where Parakey seems a little bit more focused than the other WebOS entries. A WebOS should help you not only get to your data from everywhere, but publish and synchronize it with other users. (See: RSS, JXTA, and SyncML.)

A WebOS might need to handle some tasks where the programming environment of a web browser cannot execute tasks quickly enough. I've done plenty of assembly language programming in my career, but it is almost always only needed in a very small part of even complex algorithms. For the vast majority of software, the environment should optimize for ease of development. Dynamic type checking is better than static. Automatic memory management is better than manual. Programmers should only need to focus on the problem at hand. If the problem is the need to express some control flow, then just think about the software techniques required for that. If the problem is to create a high-performance video codec, something I do frequently, then worry about the individual machine cycles in your tight loops. Don't make programmers think about all of the problems at once.

The case of media manipulation seems to me to be one of those areas that is simply too intense for coding in JavaScript with today's interpreters. This is an instance where a proprietary interface, Adobe's Flex, seems to have an advantage over existing open source options. Hopefully, this is an issue that Parakey's JUL will address.

Should it also provide window management? This seems to be a popular function of the early WebOS entries, but I don't necessarily see the point. Web browsers already support multiple windows or tabs, though the idea of bringing up a desktop on remote computers in a predefined state has some appeal to me. What should be done by a web operating system is to clarify and distinguish the roles of software modules along the lines of the model-view-controller, or simiarly useful, pattern. This would allow web applications written against a WebOS to be immediately more accessible.

Conclusion
Some say that programming will always be difficult. This may be true for highly-optimized, widely-deployed, well-structured, and cutting-edge applications, but the definition of programming is a bit of a moving target. I'd be happy to get more non-engineering people introduced to a programming environment where creating the "Hello World" application is truly trivial and creating the next YouTube is truly possible. That environment, where you can be self-taught and all of the tools are at your fingertips, should be among the goals for any WebOS application programmer's interface definition.

Try migrating your wife's computer from WinXP to Mac OS X (Part 1)

2006-12-13T09:25:00.000-06:00

It shouldn't come as a surprise to most of you that moving from WinXP to Mac OS X isn't as easy as Apple would like you to believe, no matter how much they try to blame that on Microsoft. Last weekend, I brought home a shiny new Intel-based iMac, the quiet, self-contained poster child for simple computing. One cord from the wall to the display, from there to the keyboard, and from there to the mouse; and for $60 more I could have eliminated those last two cords to the keyboard and mouse as well, at the expense of changing batteries once or twice a year. My wife tells me it took her a minute or so to figure out where the actual computer was and find the DVD drive slot. I mention that as a bit of a praise, actually, because us computer folks can really be pretty ignorant of just how confusing something like that can be for the completely uninitiated. Of course, it certainly wasn't trivial for me either.

Backing up the PC
I started by making a copy of her complete hard drive onto an external USB hard drive using Second Copy. About 50 files wouldn't copy. I looked at the log and I don't think any of them are important, but how am I supposed to really know? None of them looked like a data file name that my wife would have assigned, but I wanted to duplicate her PC settings to a virtual PC, so I also ran the Windows XP Files and Settings Transfer Wizard. Check out these notes from the helpful article on using the tool:

Don't wander too far away because the collection process occasionally turns up a file that can't be transferred, such as a .dat file, and asks how to proceed. Just click Ignore. After the collection process is complete, you'll get a list of those files. If there are a bunch of them, highlight and copy the list into Notepad and save it.

Sure enough, there were about 50 or so files that wouldn't copy again. Reading further down in those instructions for a better idea of what to do with those files yields a less than ideal response:

After the transfer is complete, you can copy over files that you want but the wizard couldn't transfer. Now your new computer is ready to go, and you didn't have to repeat the same configuration chores you performed to setup the old one.

Just why is it that these tools are written to solve half the problem and leave the rest to magic? I have no good idea if those files are really needed by any of the applications. I already tried to copy most of them with different tools. What magic should have happened so that I could copy these files now? No hint whatsoever is given on how I'm supposed to release the locks on those files. Most of you will say that those files probably weren't important, but how is that supposed to make Joe Average computer user feel, especially if one of them was important?

Initializing the Mac
Prompted by the Mac's migration assistant started by the initialization software, I chose to give myself a jump-start by importing my account and applications from my G4-based Mac Mini. This was relatively painless and taught me how to reboot my Mac Mini in Fireware target disk mode and introduced me to other boot key combinations. I was a bit nervous because most of my Mac Mini applications are not Universal. It seems that all of the programs in the Applications folder, such as Microsoft office, the ones that are actually "bundles", work fine, transparently running Rosetta.

Microsoft Office is one of the applications that got copied over, so I payed a look into if I'm contractually bound to purchase a second copy. Office ran fine on the new Intel-based iMac, but it seemed to detect when I was running one of the applications on my Mac Mini. It left me wondering how close big brother was watching. In function, this is actually pretty nice to keep honest people honest and doesn't bother me. In theory, however, I can imagine the folks at the EFF having some issues on how this affects your privacy.

The programs I had built and installed under "/usr/local" had not been copied, but Fink programs under "/sw" did get copied. The Fink install tool worked, but none of the installed applications worked. I did a quick 'file binary_executable' and read about OS X binary executable types. I also read Apple's description on what Rosetta is supposed to run. My methods were a bit unscientific. I quickly moved on to more urgent matters about which my wife would actually care.

Moving the Data
The most valuable bits of data on my wife's computer, as far as I know, are her photographs, her music for iTunes and iPod, her Microsoft Word documents, some drawings, Quicken data, and all of her Microsoft Office e-mail and contacts. The Apple site topic on data migration told me:

Tip: If you're moving files over manually, you'll save yourself some time down the road if you organize your files during the process from the get-go. For example, move your My Pictures photos from your PC to your Home folder's Pictures folder on your Mac, move your PC's My Music song files into the Music folder on your Mac, move your PC's My Videos files to the Movies folder on your Mac, move your text and PDF files to your Documents folder on the Mac, export contacts to vCards on your PC and import them into Address Book on your Mac, and so on.

Okay, this is a little bit helpful for the uninitiated, but I quickly found myself jumping forward without the proper amount of planning anyway. What this tip drastically fails to tell you is anything practical about how each of those tools organize the data once you've moved it over. The best example I have is what happened to the photos.

I copied her entire "My Pictures" folder onto the Mac into her Picture folder. Originally, she used her HP camera software to import an organize her photos, leaving each "roll" of photos it its own subdirectory names after the date the photos were imported. There were also several subdirectories that she had copied off of my machine that had names like 'triptoeurope2004'. Well, I figured, she's going to want some tool on this machine to manage all of her photos as well. I installed the HP software, but I figured that it would likely be a bit easier to support her if she went the pure-iLife route.

iPhoto didn't remove originals after performing the import, so I removed them myself. They take up way too much space, the single largest body of her data, to leave many copies on a single drive. This was probably not a great idea, since iPhoto put them all in one roll, and not in multiple albums either. Oh, well, I guess she needs something to do on this new computer, rather than just enjoy the organization that existed on the old computer.

On to the music. This has to be simple, since all those people are switching to Macs because of iTunes and iPods, right? Well, Apple certainly has thought about moving iPod users from a PC to a Mac:

Step 2: Empty your iPod

To make your switch as painless and efficient as possible, you should clear off your iPod. We recommend emptying it completely of all your music. This sounds like a radical step, but don’t worry. Your music already resides on your PC, so you’re not in danger of losing anything. (You’ll need to re-copy all your iTunes music onto the iPod anyway — more on that in a minute.)

What?? Forget that I just happened to not do things in this order, but would I really want to? Yes, I do get the fact that there is a copy on the PC. In my case, I have this fall-back plan where if my wife doesn't like the Mac, then I'll simply take it and leave her on the PC. Also, the photo data is bigger than what would fit on her iPod and little consideration seems to be given to that possibility. Doing a scrub-job on her iPod sounds like it could get me in a lot more hot water than I'm in already for simply proposing that she move to a Mac at all.

I wanted to move iTunes playlists, not just the music. The instructions left me a little nervous of what mess I'd need to clean up, but they did work fine.

Moving Mail
Buy this, buy that. Apple told me I needed to purchase yet more software to do the migration, if I really wanted it to be easy:

For easier moving, you might want to consider Move2Mac, a third-party application that makes the moving process easier. Not only will it move files from your PC to your Mac, it also transfers other items such as your email account settings and address book, Internet Explorer bookmarks, desktop backgrounds, dial-up Internet settings, and more.

After spending over $1000, what is another $50? $50 is what it is! If Apple didn't find it worth adding that to the cost of the iMac before I bought it, I don't see the point now. Well, I'm about to learn why it is worth $50 and Apple is stupid.

Microsoft has a nasty hold on your e-mail once it is in Outlook. I'd never thought about trying to get out of that trap using IMAP, but it seemed like a solid idea. If I wanted to move my mail simply with IMAP, I needed to create a .Mac account which provides an IMAP mail box, since my ISP doesn't provide IMAP. That solution has a recurring fee, so it is time to turn to the world of open source.

I initially got the idea to use IMAP and create an IMAP server by reading a blog entry by Paul J Lucas on configuring an IMAP server on a Mac Mini using Dovecot and only stumbled upon the similar Apple recommendation later. I had Fink installed, so I figured installing Dovecot should be simple. Going in loops several times, I never could find a Fink distribution that included Dovecot and I got eerie impression that Fink was dead based upon where the Fink FAQ sends you for mirror status:

Q3.7: Can I see what the current status of rsync mirrors is?

A: Yes, go to http://finkmirrors.net/status.html

Which yields:

Site Error

An error was encountered while publishing this resource.

Debugging Notice
Zope has encountered a problem publishing your object.
Cannot locate object at: http://www.uptime.at/uptime/status.html

Giving up on Fink, I went to DarwinPorts for Dovecot. This installation when happily along, but configuration was still a bit of a headache. I based my configuration file on Paul's blog, but I needed to go to the Dovecot Wiki and read the quick configuration page to figure out how to do the PAM setup.

Setting up Mail.app was relatively simple, but because I signed my own certificate, I regularly get a warning message that I need to fix at some point. The more frustrating part was moving over the contact list. I could have tried to export the contacts using vCards, but writing a program just seemed silly. I extracted the contacts from Outlook 2000 without any hang-ups. Problems came when I tried to import the created .CSV file into Mail.app.

The Mail.app import function was actually pretty intuitive, which is good given the small amount of instructions. I was able to figure out that "postcode" should be mapped to "zipcode" and just left off the third line of any mailing address, but I won't go into that here. The process was intuitive, but not necessarily simple or fast. When I finally hit the button to go ahead with the import, nothing happened. I was able to flip through all of the contact records fine, so I thought. There was that one point where it hung on me a long time and I ended up restarting the import. Okay, that happened about 3 times.

It turns out that the import tool was having a problem parsing the .CSV file. I didn't spend too much time trying to figure out if this was a file creation error from Outlook or an import error, but the result was an import that would hang and not present any error. Carriage return errors in CSV file caused Mail.app to not complete the import. Clicking OK over-and-over again didn't tell me why the entries weren't actually imported, even though the preview was fine. Eliminating the problem entry cleared the issue and her contacts were moved.

Maybe I should have at least spent $10 on Little Machines' O2M.

First impressions
When she looked at her new mail tool, she immediately noticed the lack of status bar. Sure, there is that spinning thing that she'll notice at some point, but there were so many little things moving from one application to another. It doesn't matter what anyone might say would be more "intuitive". What matters is that things are different now and change is bad. Peopleware has a great write-up on people's impressions of change, but I haven't found any on-line quotes I can place here.

The dock was another point of confusion. The confusion was similar to what you'd find when first starting using Windows as well, but she asked me a very relevant question: Why are there two places for things on the desktop, one on the bottom and and one on the side? I explain that one is the dock and the other is the desktop with desktop icons.

She used to have a taskbar that she could click to get between programs that are running. Now, I need to explain that she can use the dock for the same purpose, almost. It still seems quite foreign, and not in an adventurous way. Nothing in the interface gives her hints to the existence of expose, so I tell her about some of the function keys. A few notes on a post-it and that doesn't seem to be much of a problem right now.

Conclusion (for part 1)
I could go into many more details, but let me summarize this all in two words: computers suck. Sure, I've been using computers since the 1970's and I cannot imagine my life without them. I can bend them to my will and get all sorts of magic done; filling myself with that unique and utterly pointless pride that comes from getting something to work that maybe only one other person on the planet has seen. Yet, the task of moving data and applications from one computer to another is something any computer user will experience multiple times in their lives if they are blessed with longevity. My wife sees this all as some sort of inexplicable torture that could only be motivated by the most evil and twisted forms of geek pride. I can try to explain that this is all in some grand vision of making both of our lives ultimately easier, but I haven't found the parallel universe where that actually makes sense. Computers suck.

Paper Airplane and Web Operating Systems

2006-12-12T07:57:00.000-06:00

I've got a few posts in the works, but reading Brad Neuberg's blog post this morning on HyperScope has got me itchy to mention one of my pleas to the folks creating web operating systems. It was Brad's reference to Paper Airplane that has made me lose my patience. Paper Airplane is a JXTA-based project to allow anyone to serve up web content without a web server.

Paper Airplane is a Mozilla plugin that empowers people to easily create collaborative P2P web sites, without setting up servers or spending money. It does this by integrating a web server into the browser itself, including tools to create collaborative online communities that are stored on the machine. Paper Airplane Groups are stored locally on a user's machine. A peer-to-peer network is created between all of the Paper Airplane nodes that are running in order to resolve group names and reach normally unreachable peers due to firewalls or NAT devices.

Parts of Paper Airplane have been modularized into the P2P Sockets project, a reimplementation of standard Java sockets on top of Jxta and ports of standard web servers, servlet engines, etc. to run on top of a peer-to-peer network. P2P Sockets is at a 1.0 beta level, while Paper Airplane development is just beginning. Paper Airplane code will be posted to this site as it is developed.

See the demo screencast of Paper Airplane in action to get a quick overview.

Well, the Paper Airplane demo is starting to look pretty good. The bee in my bonnet is telling me to try to reach those Web OS folks, namely YouOS and Parakey, and make sure they aren't leaving this great research on the side of their efforts.

It must be among the key objectives of a Web OS to provide a programming layer, core set of services, and guided user interface paradigms. Decentralized hosting is fundamental among that set of services as it is completely necessary for privacy, reliability, and ease-of-use. To require centralized hosting, that is, to fail to provide for all users to be service and content providers, would be an devastating sin.

Expect more on this topic from me soon.

The Future of Digital Media Includes Participation

2006-12-06T09:45:00.000-06:00

[I originally wrote this article on August 30, 2006, before Google purchased YouTube, but I think it is worth sharing here.]

There is a huge push to provide the next generation of digital content distribution to consumers that is more responsive to their desires. Today, content is typically created by large production companies, like Disney, then distributed by cable and satellite TV carriers. In the move to IP set-top boxes (IPSTB), there is a notion of giving consumers more "on-demand" choices. Largely being missed is just how much control over available digital content consumers will have. New developments in online social networks are showing us that many consumers are interested and capable of producing content—and there is an audience.

The split between traditional media and a new field of participation media comes when the audience is given mechanisms to respond and engage.[4] The traditional path is to provide the audience with more choice, be it through cable and satelitte distribution, "on-demand" programming, or the forthcoming IP set-top boxes. Participation media, instead, gets the audience involved, providing opportunities for everyone to be a content creator, to distribute the content, and to present content in new venues. YouTube has gotten things started by allowing small video clips to be shared and rated on web pages. RSS media aggregators, such as FireAnt or Democracy TV, go a bit further by enabling subscription to full-length videos in a more decentralized fashion. These services are just the start in the creation of a new digital media infrastructure where the audience can reach entirely new levels of content targeted at their interests.

YouTube

YouTube has taken ownership of 43 percent of the online video market[1], is delivering 100 million videos everyday[2], and has an audience of up to about 20 million viewers, an increase of almost 400% in 6 months[3]. With this degree of success, YouTube is obviously providing something that viewers like. In similar fashion to many web site startups today, they're following a user-first formula for attracting viewers, giving the opportunity for the users to turn the site into something they want.

Anyone is welcome to upload a video on YouTube and then share the link with friends. Offensive or illegal videos may be removed from the site when complaints are received by the "flag as inappropriate" link below the video. Each publisher is allowed to keep each video shared privately amongst friends and family, or to make it public and seek to make it to the "most watched" video category. With relatively few restrictions, and so many content producers, the video library is vast and potentially difficult to navigate without some help.

To provide help navigating the content, YouTube collects many statistics on the videos uploaded and includes a one-to-five-star rating scheme. Using this rating information, the number of views of a particular video, comments made by viewers, and other information, YouTube is able to provide suggestions and categories of videos the viewer might find interesting. Tags are collections of words describing the topic of the video and it is quite easy to look for popular videos with similar tags that have been rated highly by other viewers. All of this data management makes it quick and easy to be entertained by the huge library of content.

I'd be a bit surprised if anyone couldn't find something on YouTube to keep entertained for weeks on end, but you might notice the current video quality level of YouTube is less than stellar. While some people are frustrated with the quality, it doesn't seem to be affecting the success of YouTube. While many viewers will pay for the quality of presentation provided by technology such as high-definition televisions, the large audience of YouTube shows that convenience, customization, and creativity, even at a minimal quality level, will bring viewers.

RSS Media Aggregators--Television for Participation Media

An RSS feed is the equivalent of a television broadcast tower for the Internet. RSS, or Really Simple Syndication, involves a web-link (URL) and specially formatted information describing the subject matter,author, when new content is available, and other information that might be used to determineinterest in the content. Most web browsers, such as Firefox, provide some support for RSS feeds, but do not natively handle all of the media types or provide significant automatic retrieval of content based upon the feeds.

An RSS media aggregator is a computer program that acts as the equivalent of a TV tuner and a TiVo, allowing a user to surf channels, find the content they desire, and automatically download the latest episodes without needing to manually explore web sites. Unlike traditional media, RSS feeds can be served from any computer on the Internet with a web server and there are many servers providing publishers these feeds for free. While today's RSS media aggregator programs and RSS feed servers can be somewhat easy to use and are centered around participation media, they solve a different set of problems than YouTube and don't yet provide all of the same features.

See the Josh Kinberg interview on XOLO TV.

Both FireAnt and Democracy TV are RSS media aggregators capable of utilizing BitTorrent to provide fast downloads of popular content, without the need to have powerful web servers involved as with YouTube. If RSS is like the television broadcast tower, BitTorrent is like the power generator for that tower. Utilizing BitTorrent, every computer used to download media content becomes a server for that same content. For every viewer who downloads a video, the download for every new viewer will be faster. The additional download capacity and decentralization provided by BitTorrent allows for higher quality videos to be served. Wikipedia refers to this technology as "broadcatching"[7] and the term connotes the many distributors to one consumer relationship[8] of these BitTorrent-enabled RSS media aggregators.

In addition to solving the bandwidth problem for publishers, broadcatching also enables revenue streams not available when using YouTube due to restrictions on posting advertisements.[9] Rocketboom, a popular video blog providing new content everyday Monday through Friday, chose to interact directly with advertisers and claims to reject product placement.[10] Instead, the blog creates ads directly for their advertisers, such as Earthlink.[11] This degree of control over content, quality, and availability, that can't be delivered on YouTube, will motivate publishers to look elsewhere when doing more than giving away random clips.Democracy TV has a separate publishing component called Broadcast Machine.[18] This software integrates with a web server running on a computer to create a web site for publishing media content. Since the publisher controls the web site, there are fewer restrictions on what content can be published, and what video quality level can be achieved, than with YouTube. Despite the existence of Broadcast Machine, publishing content using broadcatching is still more complex than the file upload feature of YouTube.

In addition to the added complexity of publishing, the ease of finding content suffers from a more diverse body of publishing practices. The tags on content are much less likely to be stored in a consistent manner or to be the same as related content. Statistics and ratings on content won't necessarily be stored in a single place and there are more reasons not to trust the data that is available. Attribution to the original author is also a serious issue for both YouTube and any broadcatching environment, but without a central resource to resolve disputes, broadcatching is even more susceptible to false claims of ownership.

Even with the publishing issues, the need to download new software to collect broadcatching feeds could be the biggest barrier to wide acceptance. Microsoft's next version of Internet Explorer will provide some native RSS support[12], but the functionality will likely only be similar to Firefox and performance will be limited compared to the open-source broadcatching aggregators already available. Concerns over copyright infringement will keep companies like Microsoft moving slowly towards broadcatching. Research Microsoft has published recently on a technology they call Avalanche[13], a competitor to BitTorrent, indicates they will eventually catch the open source community.

What is Next?

Fixing the software download issue for broadcatching is something that will certainly be solved. Lightweight Java, ActiveX controls, or browser plug-ins could simplify the software installation necessary to provide the desired experience. More adventurous solutions could seek to utilize the JavaScript capabilities in the latest browsers to build the functionality directly, without additional installations. Creation of such easy-to-use tools could evolve slowly in the open source community or could be accelerated by businesses or partnerships who can identify the potential gain on investment. Eventually, native support in the operating system or web browser will support the required protocols and interfaces.

An alternative to solving the software download problem on PCs is by including all of the necessary software in an embedded system. Embedded systems ship with software installed and could provide all of the necessary components for publishing and subscribing to content. There is already at least one home network router on the market today, the Asus WL-700gE, with BitTorrent included along with a hard disk drive for storing the downloaded content.[15] The current feature set is short of "YouTube-in-a-Box", but similar and additional functionality could be included in more complete embedded systems, including IP set-top boxes.

With all of this potential for involving everyone in participation media, it might be simple to lose an alternative lesson from the varied degrees of success of YouTube and the RSS+BitTorrent solutions: branding still matters. The video blog Rocketboom has begun to receive numerous mentions in the main stream media and provides some legitimacy to video blogs as a viable media.[16] YouTube has further delivered legitimacy to other forms of participation media and organized it in a way that is convenient and entertaining. Alternatively, FireAnt and Democracy TV have been around about as long as YouTube, but without the success. A quick search on PRNewswire shows 17 mentions of "YouTube" in August 2006[17], but searches for "FireAnt" or "Democracy+TV" didn't yield any useful results. Without some promise of creative quality associated with a recognized brand, it is unlikely any new media distribution venture could ultimately succeed.

References

[1] CNET article that claims "YouTube could be a steal at $1 billion" http://news.zdnet.com/2100-9588_22-6108971.html

[2] YouTube Press Release http://www.youtube.com/press_room_entry?entry=RZs9p25QDCY

[3] Growth of YouTube Audience http://www.marketingvox.com/archives/2006/07/24/youtubes_audience_has_grown_fourfold_in_six_months/

[4] 2003 paper from Agile-Media on "Understanding Participation Media" http://www.agile-media.co.uk/files/BTagilemedia_guide2.pdf#search=%22participation%20media%22

[5] YouTube video on uploading videos http://www.youtube.com/watch?v=qFyIT7rVZ0Q

[6] Why YouTube is more popular than Google Video http://googlesystem.blogspot.com/2006/08/why-is-youtube-more-popular-than.html

[7] Wikipedia definition of "broadcatching" http://en.wikipedia.org/wiki/Broadcatching

[8] Site claiming to know origination of the term "broadcatching" http://www.broadcatch.com/definition.shtml

[9] YouTube terms of use http://www.youtube.com/t/terms

[10] Rocketboom video blog request for sponsors http://www.rocketboom.com/sponsorship/

[11] Rocketboom episode with Earthlink advertisement at end http://www.rocketboom.com/vlog/archives/2006/05/rb_06_may_03.html

[12] Feature list of upcoming Internet Explorer 7 http://www.microsoft.com/windows/ie/ie7/about/features/default.mspx

[13] Whitepaper on Microsoft's Avalanche technology http://research.microsoft.com/~pablo/avalanche.aspx

[14] XOLO TV interview with Josh Kinberg http://www.xolo.tv/watchme/XOLOTV_8.mov

[15] Product description of Asus WL-700gE wireless LAN router with BitTorrent and a hard drive http://www.asus.com/products4.aspx?modelmenu=1&model=979&l1=12&l2=43&l3=0

[16] New York Times article on Amanda Congdon leaving as host of Rocketboom http://www.nytimes.com/2006/07/07/arts/07rock.html?ex=1309924800&amp;amp;amp;amp;amp;amp;amp;amp;en=20c360b0d2e505ef&ei=5088&partner=rssnyt&emc=rss

[17] PR Newswire http://www.prnewswire.com/

[18] Participatory Culture, who created Democracy TV http://participatoryculture.org/

Finding a voice (the problem with blogs)

2006-12-03T08:38:00.000-06:00

I've been quite hesitant to start a blog with any actual content. From the ones I've read, it seems most folks aren't nearly as paranoid as I am. It is absolutely nerve-racking to think about how much information about me is available on the Internet with very little effort. Can I avoid my slightest fear that someone is going to hunt me down and poison my dog because I accidentally offended them?

There is also the issue of intellectual property rights and proprietary information. Will I slip up and give away something that is really owned by my company, get fired, get sued, and make my company go bankrupt? Will I give away my billion dollar idea to some ninny who then corrupts it to kill every puppy in the country?

And what about the whole deal with using someone else's server to share these ideas? How do I know they won't burn to the ground just when Bill Gates was going to read my latest blog entry on why he should use his foundation to cure a disease that would otherwise kill every puppy on Earth?

Nevertheless, I've decided the risk of NOT starting a blog is too great to continue prevaricating around the bush. Living in ignorance of the value of my ideas, not being exposed to necessary feedback, isn't acceptable. Experiencing the problems of maintaining a blog is one of the best ways I can imagine to be a part of the solution. I hope that you'll join me.