Skip to content

Technology

The iPhone Moral Quandary

Gizmodo covers what’s been on my mind since it was announced Apple’s iPhone partner was AT&T: the moral quandary of doing business with AT&T.:

So what we have is a company that doesn’t have privacy at the top of its priority list, not to mention the anti-trust laws of this country. It’s setting terrible precedents left and right, and its vast power that comes from its huge size makes it all the more unlikely to change for the better. We, as contentious, tech-savvy individuals, should go out of our way to deprive this company of money, power, and influence.

And for more information about AT&T, visit the EFF’s page.

The above paragraph sums up exactly why I won’t buy, or even consider, an iPhone.

Microsoft's Linux patent deals

As a long time Red Hat stockholder, let me say thank you to Red Hat’s leadership for flatly rejecting Microsoft’s overtures for interoperability and protection from patent suits. From the Yahoo! News article:

Microsoft made its intentions clear on Friday: It wants to work out a cross-licensing deal with the largest Linux vendor on the market that would look much the same as its recent agreements with Xandros and Linspire.

Red Hat quickly dashed all hopes, standing on its previous statements from last November, issued in the wake of the controversial Novell deal. Red Hat left no room for misinterpretation when it said the company would not compromise on its open-source roots.

“An innovation tax is unthinkable,” the company said in a statement. “Free and open-source software provide the necessary environment for true innovation. Innovation without fear or threat. Activities that isolate communities or limit upstream adoption will inevitably stifle innovation.”

To Red Hat, Ubuntu and all the others in the future who reject this deal: Thank you.

Writing Foresight Docs: Part 5

No, your eyes aren’t fooling you, the Getting Started with Foresight Linux User Guide is complete, and ported to Docbook. (Click through to see a larger picture at flickr.com):

foresight-userguide1

I was traveling for most of the week for my day job, but I did a little writing after last weeks post, then a flurry of activity Friday and Saturday. Last week, I was mostly content complete, with tons of formatting left to complete in almost every document, including:

  • Linking all URLs
  • Fixing all bullet points
  • Adding arrows to directions for clicking in the menu
  • Fixing the indentation errors
  • Resizing all screenshots to 510 pixels wide

The above items were almost all completed Friday, but I still hadn’t started the biggest challenge, which was writing a Table of Contents. Looking through the source code of various other Yelp / Docbook files, I had seen a number of pages calling other Docbook pages, such as the GNOME Documentation Project Handbook, for inclusion using this tag:

[include href="filename.xml" xmlns="http://www.w3.org/2001/XInclude"/]

In the end, I ended up using the ENTITY tag, as found in the GNOME Documentation Style Guide, which consists of listing all the files in alphabetical order at the top, and then calling each one in the order you want within the [book] tag:

[!ENTITY APPLICATIONS SYSTEM "applications.xml"]

&APPLICATIONS;

I borrowed heavily from the GNOME Documentation Style Guide’s structure and code, in writing the default page (foresight-user-guide.xml) and create a Preface chapter. This chapter is new as of yesterday, and includes an “About” section, “What’s in this Guide” with links to each Chapter and it’s summary, and a “Who Should Read this Guide” which breaks out by chapter for new or experienced Linux users the chapters they might find the most relevant.

This required me to rewrite the first 75 lines of each of the 9 Docbook files that currently make up the userguide, and change them from using sect1 tags, to using chapter tags. This actually makes it much more simpler for future contributors to add to the book, as they write their chapter and don’t have to worry about filling out all the revision history in each file, it’s updated in the foresight-user-guide.xml file instead of each individual one. I got in the zone and knocked all the files out last night, and submitted them to the Mercurial repo.

There is one bug I have yet to solve:

foresight-userguide-helpbug

In two different sections of the Userguide, the “Help” section is called, both in the Preface chapter, and it references the IRC help sub-topic instead. A bug-hunting we will go.

I am sure that I haven’t done everything in the right order or by the book – for example, I’ve found references that GNOME developers use make to write documentation files, I can guess to why, but I’m not sure, nor can I figure out how they’re set up. I’m also not sure on the translation process, other than editing the files by hand but I’ve never created a program either that has had to use a po file.

I’m also darned if I can find where Yelp, when you start the GNOME Help from System > Help, is calling the files on the right side under “Welcome to the GNOME Help Browser”. That’s where I want to put the userguide, but when you open /usr/share/yelp/toc.xml it only appears to be calling the links under “Desktop” on the left.

This has been a great experience so far, and isn’t even close to over. After I track down the bug and find a place for the userguide to live in the default documentation, it’s time to take Foresight documentation to the next level. The content written so far is not set in stone. In some cases, it only skims the top of what should be included in a given chapter, there are huge holes of information not even presented in the current guide, such as a better installation overview or printing, and more screenshots could be sprinkled throughout. Other sub-chapters could be written on specialized topics, such as installing on a Macbook or running OpenBox.

A process still needs to be developed to cull documentation on the wiki to live offline in the userguide. Documentation should be a living, breathing thing that grows with the operating system, not something that grows stale. (Quick sidenote – the fact that GNOME still ships with the GNOME 2.14 Desktop Accessibility Guide and the GNOME 2.14 Desktop System Administration Guide in the default help page ticks me off to no end. Now that I have some limited experience with Docbook, it’s time to give back). Taking user contribution submissions to the wiki and putting them in the userguide should be a high priority. Hopefully, the work done on the userguide so far can serve as a base for future contributors to continue to add content to, and people will find it useful as they use Foresight Linux.

Virtualization Bandwagon Jumping

I decided to jump on the bandwagon and tried out my first appliances today, using the free VMWare player, and a couple of appliances from rpath.org.

Working on Foresight, a number of the images published are for various virtualization technolgies, such as VMWare, Parallels and Xen. Following the VMWare installation instructions in the Wiki, I installed VMWare on Foresight 1.3, downloaded 2 appliances, and was up and running in about 5 minutes.

I am starting to see why these are all the rage right now (at the last TCLUG meeting, a lot of folks put Virtualization on the list for a future speaker to come talk about). From using an image for testing, to installing multiple appliances on a server for specific applications, there are some pretty cool use cases that become possible.

And yes, I know I’m late to the party on this topic, but better late than never. 🙂

Here’s a screenshot of Openfiler, a NAS appliance running in a VMWare player:

vmware-openfiler

And here is a screenshot of Openfiler running, and a WordPress-Multiuser appliance just starting to boot up:

wpmu-openfiler

Click through to see larger versions on Flickr.

Writing Foresight Docs: Part 4

Progress on the Userguide has been swift this week. Ken’s comments about having Foresight Linux 2.0 in testing in a “couple of weeks” spurred me to action. In no particular order are the things I’ve learned and accomplished this week:

  • URLs. Again, it’s just a matter of re-wiring my brain from HTML to Docbook’s format. For example: [ulink url="http://www.openoffice.org/product/math.html" type="http">Math here[/ulink] (replace brackets with < or >) links to the Math page on OpenOffice.org. Similar, but different. And god knows I’m no HTML expert to start with.
  • Bullets have been driving me crazy. It was just one little thing, adding the mark=”bullet” to the tag, i.e. [itemizedlist mark="bullet"]
  • 3 of the 5 last pages created were created with zero syntax errors. Yes, pride cometh before the fall. All it means is I’m starting to get the hang of this. And I haven’t started doing any of the advanced formatting yet.
  • All pages have been committed. There’s some editing to be done (more on this below), but the directory structure is complete, all screenshots are uploaded,and the copy is complete in all XML files.
  • I’ve learned more Mercurial commands, such as hg pull and hg update, as I’ve worked on this on my laptop and desktop now. And I experienced a moment of panic after editing a file and not having done a pull. But I figured it out, thankfully.
  • I added a TODO file in the repository, but it probably needs to be updated more often.

Things left to do:

  • The first few pages need major formatting updates, especially on removing the indentation.
  • All pages need to be reviewed and edited for the correct URL tags.
  • Bullet points need to be fixed in almost all the pages.
  • Screenshots need to be resized to 510 pixels wide (so they print correctly, per the GNOME Documentation Handbook guidelines).
  • I still need to research, learn and build a Table of Contents.
  • I need to add some advanced formatting, specifically the arrow labels when showing how to access menus to run applications. (The tag I believe).
  • I still need to research on how to add this to the default Yelp page in GNOME, and how that will work from a packaging perspective.

Paul Scott-Wilson asked a great question in IRC last night, regarding whether Docbook repository or the Wiki will be the master copy of the userguide moving forward. My recommendation would be that Docbook would be the master copy, put together from the text on the wiki. This way it gives users a chance to contribute to the userguide on the wiki, adding new copy, having it proofed, and then moved to Docbook. The Printing section is a great example of this, it’s 80% complete on the wiki, but it needs to be 100% to be included in Docbook. (Jonathan Brickman, where are you? Please finish the Printing page!) Additionally, the Docbook repository has source control, which would make it easier to manage over the long term. Opinions or thoughts? Leave a comment below on the blog, or email me at pcutler at foresightlinux dot org.

Progress will be small to non-existent as I have to travel for my day job. This probably means no blog updates either. More to come soon.

Last.fm

I’m a big fan of Last.fm and since I started using Banshee, I’ve reported all my my music through it. A couple of tools came to my attention today.

Digg linked to the Mainstream-O-Meter to measure how mainstream your listening habits are. Digg, being the force they are, have made the site go offline temporarily. My music came in at 68% mainstream. 68%! I like to think I’m a little more eclectic, but maybe I’m not. Or maybe tech geeks like me who use Last.fm just have similar tastes. 🙂

Pscott linked the second one, LastGraph, which graphs out your music listening habits over time. You can set the background color / theme, and the date range you want to graph.

Here’s my 2007 graph:

2007-music

And here is since I started using Last.fm in Oct. 2005:

all-music

Click through to Flickr to actually read them. A couple of notes:

  • I hacked my Xbox, and added Last.fm reporting. My wife listening to music through it really skews it. (Dixie Chicks or U2 anyone?)
  • I’m definitely a streaky listener. I get stuck on an album or artist and listen to the crap out of it. (Liz Phair, Chili Peppers, The Shins)
  • You can tell when I installed my home theater in August of last year. From August to December, I wasn’t spending any time in my office on my PC. It was all about the new, big TV. The little music I listened to was on the Sonos through the network. (I so wish Sonos had Last.fm reporting built-in!)
  • I also listen to a lot of 89.3 The Current, both on the radio through the home theater, and streaming online through Banshee. That is not reflected in the graph. That is truly eclectic listening.

I’m a big enough fan, that I’ve actually subscribed for over the last year. I can’t say I’m thrilled by the recent acquisition by CBS, but I love the statistics Last.fm collects and lets me share, both on their website and through the badge on this blog.

Writing Foresight Docs: Part 3

My original intent in this continuing series on Writing Documentation for Foresight was to post weekly, but I just had to share the latest news.

With Paul Scott-Wilson’s help in IRC last night, the Userguide’s first two chapters are now working in Yelp. Pscott shared a diff file fixing some syntax issues, and pointed out I could just run yelp installation.xml to display the Docbook file in Yelp, or if it crashed, the terminal spit back all the errors and the lines to go fix them on. (I really do need to use the command line more.)

After spending a couple hours on all the errors that the terminal was yelling at me about, we now have Yelp displaying the Userguide (with images!):

userguide-yelp1

There are still a number of typo’s I’m finding, especially as it relates to bullets and indentation, but the menu’s and links are working, the content is displayed, and best of all, no errors when starting from the command line. Check it out yourself from the Mercurial repository, it’s up to date.

Next up: Learn how to tie the docbook files together (Pscott pointed me at this link: http://www.sagehill.net/docbookxsl/ModularDoc.html) and package them up in Foresight. These first two chapters took me longer than expected to port to Docbook and re-write, so it’s probably a good idea to see if this even works.

Writing Docs: Part 2

Last week, I kicked off the first blog post in my ongoing adventures to learn how to write GNOME documentation, posted as a long rant about my frustrations in the tools and information available. This week in part two, I’ll cover the start of porting the Userguide to Docbook, the tools I’m using, how I’m learning, and my unanswered questions.

After downloading the source for gedit, banshee and seahorse, I started browsing through the XML files to learn the structure and tags. I was using Gedit, but then on Tuesday Og posted about Geany and I decided to give that a try. (And of course it’s in the Foresight repos!) I mentioned it in IRC Thursday night as my new favorite tool for writing Docbook, and Ken recommended I use Mercurial for revision control.

geany-gedit

Ken set up a Mercurial repo for the userguide with the other Foresight repos, and answered my questions on using Mercurial as I quickly scanned the Mercurial documentation. Over the next couple of days I tweaked my Mercurial setup, fixing the author link with a tip from Ken, and getting Nano to be my default text editor as set in my .bashrc file.

One of the weird things I learned with Docbook, is that the section tags, and as you can see in the Gedit screenshot, having nothing to with creating sections in the documentation, rather they are the sublevels within a given chapter. I still don’t understand a number of the tags used by default, such as guilabel, which appears to be a bold tag. I fired off an email to the GNOME-docs mailing list this morning, and Leonardo Fontenelle posted links to the Subversion repositories with the handbook and styleguide, which I’m slowly going through today.

For the Userguide itself, we are creating a folder for each chapter, rather than creating one big XML file for Yelp in Mercurial. I’m hopeful a script can be written to tie the XML files together, but I haven’t even started looking at how you take these files and get them to display in Yelp. I’ve only finished chapter one, and chapter 2 is just over halfway done. There’s a lot of copy / paste going on, as I build the docbook structure for the chapter, then copy from the wiki to a text file, and copy chunks from that to the XML file. It’s slow going as I have to review the tags, and I’m just re-using the structure and tags I see used in other GNOME help files. But I learn best by doing, and repetition. At this point I have no idea if it’s working or not, or how many errors each file may have, which I won’t know until they’re displayed in Yelp. My goal is after I finish chapter 3 to ask for help in tackling that piece, in getting the files to display in Yelp, I’m assuming in a FL-1.

I’ve also mentioned this in IRC, but it’s really interesting for me on a personal level to be putting in to practice all the development practices I’ve read about over the years. From creating the source XML file to pushing the files in to a revision control system, it’s an interesting feeling building something from scratch. And this is just the beginning – once I have a few chapters I’ll need to learn how to package them for inclusion in Foresight, and then update the userguide with each release.

The only downside? With the Mercurial repository being public, you’ll be able to see if I’m working on the userguide or slacking off! No pressure there at all….

Release Day! Foresight 1.3

It’s release day for Foresight Linux 1.3. Nothing gets your adrenaline flowing like release day as you try and get all your tasks done to help out. Not only did we release the latest and greatest version of Foresight Linux, including GNOME 2.18.2 also released today, Issue #3 of the Newsletter is out. Here are some links to keep you busy:

  • Foresight Linux 1.3 release notes
  • Go download Foresight! We have installable CD & DVD images, and lots of Live Media, including VMware images, Parallels / QEMU images, and a LiveCD will be out in the next day or two. Why aren’t you using Foresight Linux yet?
  • Issue #3 of the Newsletter. Including a first look at the next generation version of Foresight Linux, 2.0.
  • The Release Day HOWTO. All the different tasks that go into release day. (Feel free to add whatever we’ve missed!)

Use it, love it, and help us make Foresight even better. Stop by #foresight on FreeNode in IRC – we won’t bite, I promise.