Global Jam in Montréal

So we're doing it again!

It's obviously getting a bit on the late side to announce this, but I only got the confirmation for our location this weekend -- after work or when I had a second, I wrote the Ubuntu-Quebec mailing list invitation, dented about the event, and created the LoCo directory entry for this event already.

So once again, people wanting to help improve Natty Narwhal or who would like to know more about bugs, triaging, fixing bugs, testing the new release or even writing documentation for applications, and living around Montreal, Qc, don't hesitate to come join us at SUPInfo Montréal this weekend. The closest subway station is McGill on the green line, then about 3 minutes walking time ;)

We're holding our sessions on *both* Saturday and Sunday, from 11am to 5pm on each day.

SUPInfo Montréal
752 Sherbrooke West
Montreal, Quebec



Agrandir le plan

Idea #27250: Auto eth0 isn't very user friendly. Many people wont know what it is.

The Problem

In case you didn't already figure it out, the title refers to a quite popular idea on Ubuntu Brainstorm. It also refers to a bug report against NetworkManager in Launchpad: bug #386900.

This is one issue I'd particularly like to solve soon. Although it most likely won't change for Natty (given that we're in Feature Freeze, and UI Freeze incessantly), I believe the question truly can be brought to a concensus and fixed early in the Oneiric cycle (and actually be made available upstream for everyone's benefit).

I think much of the issues coming from this bug report stem from diverging expectations of people who just care about their wired connection working and likely don't need to change it all that often, and people who actively use NetworkManager's connection profiles to achieve various things.

First, some background:

Why "Auto eth0" ?

The name "Auto eth0" comes from... well, the fact that it's a connection that was created automatically by NetworkManager with the simplest default settings (that is, just use DHCP to set an IP address), and the fact that it was created for the interface eth0. As such, people with multiple wired network cards would then get one "Auto XXXX" profile for each wired card. This profile should take care of 90% of all use cases, since most people will just want their system to be plugged in, their home router to hand over an IP address and be able to get online.

What's this with profiles ?

I just mentioned that the connection names shown are profiles. This is actually very important to me and quite a lot of people, because there are often cases where one would want to use specific network settings when at work and while at home. In other words, one could use "Auto eth0" at home with a simple setup, and benefit from a "At work" profile which sets a static IP address, or different DNS search strings (what would let your computer access "planet", instead of "planet.ubuntu.com" in Firefox, for instance).

Why so many issues ?

I guess this all falls apart when you consider that most people probably won't use alternate profiles for wired connections. DHCP tends to get most things right from the start, which make profiles not very useful unless you want to do very specific things with your connection.

Add to this the fact that not everyone knows that eth0 is what Linux calls your first wired network card (instead of say "Local Area Connection" as I believe it is on Windows), and you have a nice little mess to untangle.

Fixing all of this

I can't say I have all the answers. It's still unclear to me how much information is absolutely required, and I'm well aware that we can't really please everyone.

However, I've added a proposal to the brainstorm idea (Solution #7). It goes like this:

I'm suggesting the name of the profile to be something like "Default". It should not be tied to any particular adapter.
This way, any new connection use that profile which will have default settings to use DHCP and the usual (as Auto eth0 is set). All adapters could share it, so adding a new interface to a computer would still just "work".

For notifications, I suggest the following changes:

- The title should mention "Wired network", and probably the same of the interface (eth0 in most cases).
- The text of the notification should say:

Connection established, using profile "Default"

or whatever profile in use.

Furthermore, perhaps items in the network menu shouldn't list the full details of the network card (it's full name from udev as it does now). Instead, the interface name would be sufficient. I expect people who use multiple cards to know what eth0 and eth1 mean and refer to.

Lastly, drop the "Auto" from user-created wireless network profiles too. Since they are created by the user and carry the name of the wireless network, "Auto" is both unnecessary, and possibly incorrect (since people can change the settings after creating it).

I'd very much like anyone with an opinion on this to vote on Ubuntu Brainstorm for the idea they prefer, and comment with why my suggestion breaks things for them if it does. I certainly could have forgotten things. Comments on this blog are welcome too ;)

This weekend's GeekFest in Montreal

We had a table at this weekend's GeekFest geek festival in Montreal. It was awesome! Tons of people, and even better, tons of interest about Ubuntu and our LoCo team.

We gave out CDs, stickers, some extra FSF stickers I had in my backpack, and generally told people all they wanted to know about Ubuntu, gaming on Ubuntu (we had a demo of World of Goo running on one of the laptops for a good part of Sunday), and the Ubuntu Quebec LoCo team. It was very interesting to hear people tell us they already knew about Ubuntu or used it at home, at work, etc; yet still didn't know about the local community team and the help resources we offer.

One of the things we focused on was how Ubuntu Quebec has a mailing list and forum to provide help, announce events and just generally discuss things, as well as our IRC channel on Freenode (#ubuntu-qc, for those who don't know!). Lots of people were surprised to hear of a user group for Ubuntu but very interested by it. I printed and gave out nearly 40 business cards with contact information for the LoCo team.

I am very happy to have been helped by two very active members of the team: Christian Parent (Mobidoy) and Philippe Gauthier (deuxpi), and joined on Sunday by Eric Beaurivage (sipherdee), another LoCo team member. Without them, we certainly couldn't have been able to speak to so many people, and we definitely wouldn't have had any time to visit the other kiosks (can't just stay sitting... if you hold a kiosk in a conference, just got to go see the other things!).

Christian always has very cool ideas, this weekend it was to show his new laptop sticker (a mouse pad glued to the laptop).

Some other interesting aspects:

To our right was the kiosk of devLAB, a project to start programming contests, identify new technologies, etc... Did I get this all right? Sure hope so. The great thing too is that they were interested by our Global Jam ideas, so there may be collaboration on that aspect to come for this cycle's Global Jam event in Montreal. That still needs to be discussed on the mailing list.

We met with someone from Foonzo Café, a new café in Montreal near Peel metro which runs all their systems on Ubuntu! They have some 80 seated places, so we may consider holding the Montreal release party there for Natty. Check how the discussion unfolds for this on our mailing list.

And last but not least, we met with Carlos and his brother who started "Carlito's Contraptions". They work on Nao the robot to develop applications, have it do stuff... While Nao doesn't exactly run Ubuntu (it's really a stripped down Linux with the bare minimum), their development systems are Ubuntu. They were nice enough to allow us to take action shots of Nao with a Ubuntu logo sticker. First it was on a GeekFest pin attached to Nao with sticky-tack, then they put another sticker directly on Nao's right arm. Rock on guys!

Take a look at all the pictures on my Picasa Album: "GeekFestMtl 2011".

How to contribute to NetworkManager (or nm-applet)

Since NetworkManager (and all of the attached parts; VPN plugins, clients, backend...) is such a complex system, we're always looking for people to help out in whichever way they can.

One of the things I'd like to focus on this cycle (even if this announcement should have come long ago), is test cases and generally getting a good grasp of what works and what doesn't with NM, the clients, or plugins. Test cases are useful for us to know that things are performing as they should and even more important where development snapshots are involved, given the "in flux" nature of the code we're providing users. It's not that it's unstable code really (in fact, it's clearly not... 0.8 is now a stable branch that got tons of bug fixes, and seems rock solid if I believe the type and number of reports we get). Still, I'm interested to know about failures. That's partly why I wrote a number of test cases on the Desktop Testing Team tracker. There's a need for more though, and that's where the help of the community comes in.

If you know of some things that are important to you in NetworkManager, nm-applet, or the VPN plugins, write test cases for them! It will help everyone make sure those remain working, iron out the small annoying bugs, and just improve on the overall usefulness of NetworkManager.

Obviously, test cases and testing isn't the only place you can help. Are you annoyed at some little thing that works, but you'd love for it to go one step further in providing an amazing experience? Then we need you.

It's also very much the way I started contributing to Ubuntu, dealing with small annoyances which would make my life easier in using the desktop every day... And it was as simple and providing support for saving group or user password for the VPNC plugin.

I can already think of a few more of these small things, such as hiding the SIM PIN when prompted for it (since it's a password)...

I've started identifying small (but important!) bugs like this in Launchpad. As for other projects, look for the 'bitesize' tag. Here's an example.
They may not all be tagged bitesize, but if there's something that almost works for you and you want to take a look at fixing it, jump in! We'll all be glad you did. The same principle applies to many of the bugs marked as Wishlist, which are good ideas, maybe some need more discussion upstream, but they are all ready to be worked on (and have varying degrees of difficulty).

If you're looking to work on NM, the first thing you may want to look at is the wiki at http://live.gnome.org/NetworkManager. It's generally also a good idea to subscribe to the mailing list (see the previous link), so you can discuss changes with the community at large. Finally, there's truly no place more useful than the DebuggingTips page even for non-technical users. It's where you can poke NetworkManager to tell you exactly what goes on. In. Details.

In the cases where changes can be reasonably integrated into Ubuntu and/or Debian directly, feel free to submit merge requests and patches. This includes helping out fixing issues in the growing indicator patch for the applet :)

Finally if you're just curious and want to help out, you should know that there is a lot of work being done at the moment to simplify NM in various ways; all of which to in time become version 0.9. If you want to know more about the plans for NM 0.9, it's here: http://live.gnome.org/NetworkManager/ApiSimplify

When I'm connected I'm always happy to answer questions and help out in any way possible, both on NM and general desktop-ish stuff. You can reach me on #ubuntu-desktop or #nm on Freenode. I'm cyphermox.

Natty nm-applet improvements

As those running Natty have undoubtedly noticed (and it has been noted on the Ayatana mailing list), we currently have a stop-gap measure (until we get connman and indicator-network magic!) for an indicator for network connections being nm-applet with a big ugly patch to make it work as an indicator.

In light of the discussion I'm referring to above, as well as a number of bugs that have been reported against network-manager-applet, I've been working on fixing these issues, including making the animations work again, re-adding icons for wireless signal strength and fixing the icons when connected to VPNs.

Most of this was coming from the fact that icons could not be dynamically composited by nm-applet when using libappindicator as it used to be doing. However, it's just about ready to all be live again:

All I'm waiting for is review of a merge request to provide the new icons needed. :)

Now, there is still a number of things that need to be fixed in the indicator patch and in the look and feel of nm-applet as an indicator. While this is still meant to remain a bridge until we can switch to connman and indicator-network, I'm looking forward to getting new ideas and to know about the issues you see in nm-applet's look right now. Jump in on the ayatana list and give us your thoughts!

Supporting the Harmony 300 on Linux

Today, I bought a Logitech Harmony 300 universal remote. At about 60$ CAD, it's really a bargain, and despite it's limited feature set compared to other Harmony remotes (I also have the Harmony 670, which has selectable "tasks"), it fits the use I want to make of it.

I had to use Windows. There is just no way this could be done under Linux, due to a variety of factors including lack of support in my favorite project, Concordance, and Logitech's choice to use a SilverLight application to handle configuration and authentication.

I'm pretty sad of the choices made by Logitech on this. Where all they had been doing to support a Linux community around their devices was to keep an old website working (and to this day, it's still working and fine for a large majority of the Harmony devices, usable with Concordance to configure remotes such as the 525, the 700, the 900, etc.), they chose to support this model with the new myharmony.com website which doesn't appear to expose the same level of control, and definitely complicates use in Linux. I don't think keeping the same old methods would have really meant such an investment to them, and I doubt exposing the possibility of downloading the same old EzHex files for programming would have been a cause for concern for intellectual property rights re. other manufacturers and systems designs.

Lack of understanding and basic support of Linux users by large corporations such as Logitech remains, I think, one of the key reasons why Linux has yet to reach and "stick" to a majority of everyday users. I believe that omitting to give alternative options to users who choose to work with a different operating system is not only causing harm to the Linux community, but also causing Logitech (just as an example, other companies are in the same boat) to lose potential customers. After all, wouldn't it be normal for the standard target users for home automation and function aggregation devices to be pretty close to the same group of "early adopters" as currently targetted by the Linux ecosystem?

Please, Logitech, get your act together. I've contacted you on this subject again. I'm sure others have as well. I think we understand you might not want to bother, but at least give us enough information so that we could still send you money through buying your hardware, but do our own support if you don't want to take care of it. The Concordance community will be happy, and I'm certain other groups of users of your hardware will, too. I doubt this always means going as far as sharing system schematics, full hardware specs or whatnot. It just means letting us know what we need to know to use the devices to their full potential.

Logitech and others currently have a great opportunity in doing a stellar job at fostering communities of users based around their products, which would not only serve as to possibly have more users, but also as a great example on how a company can succeed by leveraging not just the buying power of users, but also their willingness to support each other directly. Am I dreaming or at the very least, this could me relatively fewer expenses on support, with very little effort in sharing some information?

As for current solutions to accessing the website, Moonlight could have been a possibility, but under Ubuntu Natty I didn't even have that choice. I think the website bailed out just because I run Firefox 4.

Booting to ISO images from a USB key

I'm pretty sure this has been done before (I recall seeing a blog post about it... if you're the one who posted on Planet Ubuntu with a similar howto, let me know as I want to talk to you, at least to say thanks), but here it is anyway:

A couple of days ago I wrote this quick script to generate a roughly correct grub.cfg from the contents of a directory filled with .iso files. The goal: generate a USB bootable key that runs GRUB and allows you to choose which ISO to boot. It could be Ubuntu desktop, netbook, etc, doesn't matter, as long as you have enough room on the key.

This is done by leveraging the loopback grub command and the isoscan parameter. But first, setting it up...

You'll need (to):

• one free USB key, formatted to vfat (mkfs.vfat -F 32 /dev/sdX1) the more space the better
• create a directory called "iso" on it
• install grub on it:

  grub-install --root-directory=/media/MOUNTPOINT /dev/sdX

• this will create the boot/grub directories and install everything grub needs
• copy iso files to the iso/ directory
• run update-grub.py (available in bzr branch: lp:~mathieu-tl/+junk/bootable-iso-usb) from the key's mountpoint 
• Careful: it's only quickly tested, and overwrites boot/grub/grub.cfg from the current working directory.

Sorry for the unimaginative naming of the script.

In short, this script attempts to guess what kind of distribution is in the ISO file. I've tested desktop and alternate with success, both seem to boot and properly get you to an install (or for desktop, "maybe-ubiquity", which means you'll get a prompt for whether you want to run the live session or just ubiquity to install). All this needed was to make use of the iso naming scheme and more importantly of the contents of the ISO files, as read by isoinfo (from the genisoimage package).

Even if it never ends up being of any use, it was at least a fun little thing to write.