This means that desktop users will be able to access their networked files and folders via a couple of clicks.   Users of previous versions of Thunar who wanted to access network folders would have to hack around with FUSE file systems, or use a separate application altogether.  Configuring a special file system, or having to open a different file manager application to get files and folders on a network do not represent user-friendly approaches to networked computing.  Thus, providing network-share support from within the file manager represents a major improvement to the Xfce user experience.

Admittedly, for long-time GNOME and KDE users (or even for Windows or Mac users), adding network-share support to the file manager may not seem like a big deal. The respective GNOME and KDE file managers, Nautilus and Konqueror (or Dolphin), have provided network-share support for some time.  However, Xfce is a much smaller project than GNOME or KDE, so I’m sure that people can appreciate the effort of a small group of developers working to add important end-user functionality such as this.

For long-time Xfce users who don’t want or need the new network share support, and would prefer that things stay as simple and lightweight as possible, there is good news for you, too.  Jannis will be issuing a maintenance release of Thunar that includes several of the improvements from the 1.1.0 release, but uses the previous back-end of Thunar, called Thunar-VFS.  Thunar-VFS does not support native access to network shares.  Thus, individuals who package Thunar for their Linux/BSD distributions will be able to choose whether or not they want to incorporate the new network-share features into their packaged version of Thunar.

While the network-share support is the most prominent improvement that comes with this release of Thunar, several other improvements are also included.  Have a look at the release notes (best viewed in Firefox) if you want the full-scoop on the improvements and new features that come with this new release of Thunar.

[edit] as John Carr indicated in the comments, the GIO/GVfs back-end is the result of the hard work of GNOME developers, so credit is due to them, as well.  Also, the performance of the GIO/GVfs back-end has not been tested in comparisons against the Thunar-VFS back-end.  Thank you for the comment, John.

The primary focus of this meeting will be on team governance, as Cody Somerville is transitioning out of his role as primary project leader.  With that, we’ll be discussing changes to the Xubuntu Strategy Document.  However, there are still a few other topics to be discussed, and you can add topics to the agenda.

Hope to see you there!

Among other things, I like to follow the ‘dents (from Identi.ca) and tweets (from Twitter) from the event.  Typically, people will use Identi.ca and Twitter to share snippets about some particular topic that has come up during the conference, but I’ve found that some notices can be more helpful than others.

For example, here’s a fictitious example of what I think is an unhelpful dent/tweet:  “I’m going to attend the virtualization session! #UDS”

I saw a lot notices like this posted during the last developer summit.  Notices like these show that you’re excited (cool), and they can also help other attendees to know your location at the conference (pretty cool), but they don’t actually tell us much of anything (not very cool).  I know that sometimes you just can’t help it . . . you’re at this great event, and just want to share a bit of what is going on with the outside world.  I’m sure that this is not a big deal in the grandiose scheme of things.

With that, though, let’s take a look at some more interesting ways to make use of these social networking tools.

• Seek feedback from conference participants: “Experimenting with blip.tv for UDS videos: http://is.gd/1Fv5g what do you guys think?“  Notices like these can be used both during and after an event.
  
• Share information about a social event that will be going on after conference hours: “I’ve created a sign up page for Monday night @ the firing range. Everyone welcome https://wiki.ubuntu.com/UDS-L/FiringRangeNight #uds !uds”
• Let others know about room or schedule changes: “Due to overflow crowds, remaining Xubuntu sessions have been moved to Big Texas Conference Hall B. #UDS”  (Ok, I made up that dent.  I can dream, though, can’t I?)
  
• Inform others (okay . . . complain) about conditions at the conference: “Hmmm, my laptop kept me nice and warm during the pleniary sessions, but it’s still cold in the rooms. Anyone want to max my CPU? !uds“  After all, the conference organizers pay good money to an event site to host their event there, so rooms should be comfortable for attendees.
• Share technical information from a session (aka “live-tweeting” a session): “#uds “package-branches” is the tag used for bugs (in #launchpad) related to source package branches.” Notices like these may not make sense to everyone, but they will likely make sense to those interested in the topic.
• Presenters can use identi.ca or twitter as a presentation tool, too.  For example, Tom Johnson recently wrote an article noting that presenters can pose questions to their audience, and let the audience respond via Twitter.  This can provide for real-time feedback to the presenter about a particular topic, and can help to break down some of the barriers between the audience and the presenter.

Of course, I expect that people will use microblogging for fun, too.  I wouldn’t want for people to feel uptight about their tweets.  I just wanted to share a couple of thoughts for how people can better use microblogging at a conference, thus making things more enjoyable for those in attendance, and for those who are participating remotely.  If you have any other suggestions, feel free to share them in the comments.

————

jwc@tereska:~$ vrms
Non-free packages installed on tereska

linux-generic             Complete Generic Linux kernel
linux-restricted-modules- Non-free Linux 2.6.28 modules helper script
linux-restricted-modules- Restricted Linux modules for generic kernels

Contrib packages installed on tereska

flashplugin-installer     Adobe Flash Player plugin installer
flashplugin-nonfree       Adobe Flash Player plugin installer (transitional pack

3 non-free packages, 0.2% of 1467 installed packages.
2 contrib packages, 0.1% of 1467 installed packages.

————

This report reflects the current “free” status of the software on my system, but my system didn’t start out this way.  What we see here is the result of a little bit of cleanup.  For example, some restricted Nvidia and ATI drivers were installed by default, but I was able to remove them because I don’t have any Nvidia or ATI hardware on this computer.

Also, Valide (the name given to the Vala IDE program) was listed as contrib software on this report.  I’m not sure why that is.  I eventually removed it from the system prior to rerunning the vrms command, so it does not appear in the list above.

Anyway, at this point it looks like all I have to do to get a completely Free system is remove the flash plugin and, um, my kernel!  Then I’ll be all set. : -)

The guide also includes a link to a “color quiz” where you can get an idea of how well you know the meaning of colors in the U.S.  Unfortunately, I only got a little more than half of the answers correct.  : (

Thanks to Rhonda Bracey of the Cybertext Newsletter for sharing this on her own blog.

In thinking about UbuntuOne, there are a number of factors involved; it involves the need to build a sustainable business, trademark issues, and the level of one’s own comfort with using non-free software. To me, there it also involves issues of community, and the difference between the Ubuntu project and Canonical as a corporation.

This isn’t an exhaustive list, but the topics do allow for at least an initial framework for talking about things. So, if you’ll humor me for a couple of moments, here are a couple of my thoughts regarding these topics.

Some Caveats

First, I’ll get a few things out of the way. Yes, I’ve used You Tube and I use Gmail. The irony of my giving UbuntuOne a hard time for being non-free while I use these services is not lost on me. As for email, I have previously looked for options outside of Gmail, and am still considering other options. With regard to YouTube, there simply isn’t anything else that remotely provides something of the scale of that service in a free software context, nor do any free software services have the opportunity to provide a scale big enough to support a similar service. I think I am realistic about these things.

Moreover, I do understand that, as it is now, UbuntuOne is just a tool to synchronize files across desktops, and that I don’t have to use it if I don’t want to. I know UbuntuOne is currently available as a, “you can have a small beer for free, and you can pay money if you want a bigger beer,” service, and I have nothing against Canonical making money. I want the company to be successful.

Finally, with regard to the trademark issue, this is not a big deal to me, either, as Canonical owns the trademark, so they can violate even their own recommended guidelines if they want. No one has said that what they are doing is breaking any kind of law. It’s kind of like them painting their house pink or something. Someone else might not think it’s the best idea, but it’s Canonical’s house. It’s their decision, and that’s fine with me.

From my points above I think it’s clear that I am willing to make certain sacrifices of my computing freedom to use certain services, I know Canonical needs to make money, and I’m not concerned with how Canonical handles their trademark business.

Jim, dude, what is your beef?

My main concerns are that, while this might seem like a small application for now, it is a non-free element that is going to become more integrated with our desktops over time. Also, while Google and Twitter and Facebook may have their own reasons for keeping apps closed, Ubuntu is not Google or Twitter or Facebook, and (to me) Ubuntu (and I would like to think Canonical) operates under a somewhat different set of principles. Let me expand on these items.

UbuntuOne is currently a small service

A primary concern is that while this is a relatively simple service for now, it is going to get much bigger, and they show no intention of ever opening it up. Per the summary of this upcoming talk, there are significant plans to build more user-friendly applications attached to this closed-source web application.

I know people can get by without UbuntuOne’s cross-desktop file synchronization for now, but they are going to build a lot of other (probably really cool) functionality into this service, and it looks as though the back end of it will all be closed. If more and more applications are built around this closed web-app, it will make it a shame to miss out on some of those cool features while using Ubuntu if I want to avoid closed applications.

Depending on the level of integration, we may then find ourselves in a spot where we are using an open OS, but a good number of our favorite tools and applications are tied in with closed web-apps. As I posted on identi.ca, “If we go from having a closed desktop, to an open desktop that is strongly linked to a closed ‘cloud,’ what have we gained?” If the web becomes “the new operating system,” how will it help us if that new operating system is closed? While shipping only the open client as part of the distro may not technically violate the principle of “We only ship Free software (with the exception of some binary blobs to make some basic hardware work),” attaching it to a closed web application (to me) violates the spirit that principle.

Ubuntu != Google

Granted, what I have described above already appears to be somewhat of a reality. It certainly is getting more common for desktop client apps to be open while attached to closed web services. So why does this matter with UbuntuOne? To me, the difference is that Ubuntu, the Ubuntu community, and (even to a certain extent) Canonical are not Google. We are not Facebook or Twitter. The folks involved in Ubuntu work hard to create Free software. The distribution we work on is based on Debian, which has built itself up using the principles of Free software, and without which our project would not exist. I know that Canonical is a for-profit company, but we still have a choice here. We can’t control what Google does with their web applications. We can’t control Twitter’s Fail Whale. But we (Canonical / Ubuntu) can control this, and, to me, the Ubuntu project is supposed to be different.

We devote a lot of time to removing non-free software from our systems. Community developers work hard, paid Canonical employees work hard, and the folks in charge at Canonical spend a lot of the company’s own money so that we can remove non-free stuff from our systems, and I am thankful for all of this. With UbuntuOne, though, we’re getting more non-free components associated with our desktops when we should be working to get less non-free components associated with our desktops. It seems counter to the mission of the Free Software community aspect to have the parent company of this distribution actually introducing more non-free elements into the software ecosystem.

What really raises flags for me this time around, and perhaps I’m a little late to the game, is that we’re actually bringing the non-free components into direct integration with the desktop. It’s not like Soyuz (one of the main back-end components of Launchpad) or the (currently non-free, but soon to be Free) Launchpad, which have been developer and software building tools, and have limited integration with the desktop . . . but this actually integrates with our desktops in a non-developer-centric manner. I guess that’s why I didn’t notice or pay as much attention to the other non-free elements provided by Canonical previously – because they weren’t tightly integrated with the Desktop.

Could Canonical still make money from UbuntuOne as Free software?

I’ve got to assume that the folks working at Canonical considered whether or not they could do this in a Free manner. I have only read that the back end is closed, and that there are no plans or roadmaps in place that point to making it Free software. I haven’t heard anything along the lines of, “Yes, we considered it, but we didn’t think it would work out because of X, Y, and Z.” They are a business, and they have every right to not open up those kinds of discussions to the community, but based on the nature of their business I think it’s fair to assume some conversation along those lines occurred.

I am not a business guru, and I know that trying to make money off of an open platform in a real business world is a difficult nut to crack. That’s what we keep working toward, though, and I think that’s at least part of why so many people contribute to Ubuntu. UbuntuOne may currently have a closed back end, but with it now being released to the public, the cards are on the table. We can now talk about it. I know this is a Canonical effort, but I think there are lots of other smart people in the community, and it seems like it could be worthwhile to have a discussion about ways to monetize UbuntuOne as a Free software option. Perhaps this could be a good discussion for UDS.

I guess I should close by noting that I have written this because I do like Ubuntu, but what drew me to Ubuntu in the first place is that it is based around building Free software. I recognize that there are certain sacrifices that need to be made in areas we can’t control, but we have a choice here. Free software is what got us started, it’s what we work on, and I do not see a tremendous amount of value in fixing bug #1 if we get there by integrating ourselves with non-free networked systems.

You can check out the details on our team wiki page, but here is the short of it:

Date: Saturday, April 25th
Time: 2:00pm to 6:00pm (people may go out for a bit afterwards, too)
Location: IIT’s Institute of Design in downtown Chicago
350 North La Salle Street
4th Floor
Chicago, Illinois 60654
Who: Everyone is welcome to attend, but please RSVP via the sign-up sheet at the bottom of the wiki page.

We’ll have short talks about new features in Ubuntu, Ubuntu-Server, Kubuntu and Xubuntu, as well as some food and drinks. (Please bring a few dollars if you want to partake of the foodstuffs.)  We’ve also made an outreach to the Chicago Drupal Meetup Group in hopes of building a relationship and fostering some collaboration. We’ll see how that goes. : -)

If you have any questions about the event, feel free to be in touch.  Otherwise, we hope to see you on the 25th. : -)

How can you use this new feature?  Here is an example of how you could use it in the wiki.  In this example, we’ll look at installing the xubuntu-artwork package:

If you are an Ubuntu user who wants to use the stylish Xubuntu artwork on your system, just [[apt:xubuntu-artwork|install the "xubuntu-artwork" package]].

Of course, the end user just sees, “If you are an Ubuntu user who wants to use the stylish Xubuntu artwork on your system, just install the "xubuntu-artwork" package." (If you are a Firefox user on Ubuntu, you will also note that the link I’ve provided here works, too.  This is because Firefox also allows apt-urls to work in regular web pages.)

After clicking on the link, the user would then be prompted to choose whether or not he or she wants to install the package.  If they select yes, they are prompted to enter their password, and the system installs their software. Easy enough!

Because it is using apt, it is relying on the user’s configured set of Ubuntu repositories.  (Note: if a user is using a PPA or another software repository, those software sources would also be available.)  The installed packages can still be uninstalled via any of the regular software maintenance tools (e.g., synaptic, apt-get, add-remove programs, etc.)  In this manner, it doesn’t introduce new tools, it just provides a great new way of interfacing with them.

So . . . wiki editors . . . I now call on you to go forth and make good use of this new feature.  : -)  Let’s start using apt-urls in our wiki documentation.

Thanks to the Canonical system administrators for putting this in place, and to Matthew East for following up on the support ticket.

McCloud’s talk was interesting in a number of ways, but one aspect of it that struck me was the volume of work went into what he did.  The initial basis of the work was 10 dvd’s worth of recorded interviews with developers.  They did not allow the content of the comic book form to be dictated by some kind of marketing storyline.  The comic still stood up as a form of documentation.

Additionally:
* The use of bubbles as text-placeholders in the comic created some difficulties for translators, but they were able to make things work. He didn’t provide a great amount of detail about this.
* He loved the mash-ups that resulted from the work being licensed under a Creative Commons license, even if the mash-ups didn’t follow the letter of the license.  Google did not attempt to sue people who made these mashups for noncompliance with the license.
* He demonstrated how comic book framing can keep the use focused on one item at a time, and make it easier to explain difficult concepts in an elegant, easy-to-understand way.
* I think he referenced XKCD at least 3 times.  He likes it.
* I can’t draw comics.  :/  Maybe I can use some of this stuff with screenshots, though.

I also attended a session on ISO standards for documentation and D.I.T.A., an open-source documentation toolkit similar to docbook.  The standard is maintained by OASIS, a not-for-profit standards organization – it looks great!  We got to see snippets of it, but it costs about $200 to get a single copy of the standard. :/  Even members of the OASIS committee who volunteer to maintain the standard have to pay to get a copy of it.  I am glad that at I don’t have to pay to contribute to Ubuntu.

The best session of the day for me was the session on architecting documentation for reuse.  The Ubuntu documentation team already has some of our content architected for reuse; for example, we use docbook “entities” for repetitive items such as system and software version numbers, Ubuntu website urls and certain procedures, but this showed how it’s possible to do more.  I’m a little green as a member of the Ubuntu documentation team, but I’m eager to learn more about this approach.

I’ve also been working on the documentation for Xubuntu 9.04, which has been rebased off of the Ubuntu 9.04 documentation for this release.  What this means is that I’ve been able to use bzr to merge in changes from the Ubuntu documentation as they happen, applying them directly to the current branch of Xubuntu documentation.  This is different from prior Xubuntu documentation efforts that had been based off of a much earlier set of Ubuntu docs.

In that sense, I was starting at a bit of a disadvantage – each release brings changes and updates, not only to X/K/Ubuntu itself, but also the associated documentation.  However, by using the current branch of Ubuntu docs as a starting point for this release, and merging in updates as they get applied to Ubuntu documentation, I’ve been able to leverage the ongoing contributions of the Ubuntu documentors and keep the Xubuntu docs more up-to-date.

Using this approach took a little bit of experimenting to find a good workflow for myself, but Bzr has proved to be a more-than-adequate tool for this particular scenario.  For example, the bzr command that I’ve used most frequently as of late involves merging in the specific changes from one Ubuntu documentation revision to another into the Xubuntu documentation branch.  To do that, I’ve just reviewed recent changes to Ubuntu documentation, navigated to my local folder of the Xubuntu documentation branch, and issued a command similar to this one:

bzr merge -r211..212 lp:ubuntu-doc

Here I’m telling bzr to merge in only the differences between revisions number 211 and 212 from the Ubuntu Documentation branch.  Merging in changes between specific revision numbers allows me to cherrypick – I can merge the changes that I want, and skip the changes that I don’t want.  This is helpful because Xubuntu docs will not include the Ubuntu Server Guide (my apologies to Adam Sommer, who has done a ton of great work on the Ubuntu Server Guide for this release), so I have skipped revisions that include updates to the Server Guide.  : /

If there are no conflicts between the merged files, bzr just identifies the changes as modified files – no problems.  Files that contain conflicts are identified by bzr, too, and it is up to me to resolve those conflicts.  Once fixed, I can then use bzr to mark the conflicts as resolved.  The process still requires some manual review on my part, but reviewing someone else’s changes is much easier than writing my own stuff, and gives me more time to focus on documenting the elements that are specific to Xubuntu.

I’m still writing additional documentation that is specific to Xubuntu, but have a little bit of time remaining before string freeze.  : )  At the end of next week, I am going to be travelling to Seattle to visit a friend and her husband, and also attend a documentation conference out there.  I’m going to focus on the Design Strategies, Content Development, and Open Standards tracks.  It should be a great time, and should make for a great learning experience, too.