Fabian Rodriguez

Anne Goldemberg donne sa formation sur les wikis à la Fourmilière de Koumbit… visiblement on a sous-estimé le nombre de participants! C’est un bon problème à gérer, bravo à Koumbit pour l’organisation de ces formations.

J’y suis avec un client dans le domaine de la production vidéo (mon frère!) pour un petit projet d’implantation wiki. Drôle de journée!

Combien seriez-vous prêt à payer pour un bidule qui:

• Permet de charger 4 piles AA (donc, chargeur)
• Inclût ces 4 piles AA
• Permet de brancher un fil usb normal, fournissant 5 V à 8 types de connecteurs pour étirer la charge d’un appareil “mort” (donc permet aussi d’y brancher tout autre bidule se chargeant sur une prise USB)
• Se branche dans une prise murale (combiné à la fonction antérieure, devient essentiellement un convertisseur 120VAC -> 5V USB universel)
• Inclût un file USB vers mini-USB (le fil mentionné auparavant, avec un des adaptateurs)

Combien ?

80 $ ?
50 $ ?

Mmmhhh… 24.95 $ chez Canadian Tire, ou chez tout vendeur de bidules utiles.

Plus d’information dans le manuel d’usager du Noma RX4:

• Noma RX4 User’s Manual

Passez le mot, et pour la faillite des autres fabricants d’adaptateurs, je suis persuadé qu’on va attendre.

As a (relatively) long time Ubuntu user, occasional bug reporter and support analyst, I often deal with bug reporting and I feel your pain about bug reporting, Matt. This happens in many other free software projects, but I think Ubuntu’s popularity gives its problems more exposure, an opportunity to refine the process and maybe inspire others to learn from its mistakes and success.

Generally speaking it’s always nice if you can dedicate a few dozen minutes (around an hour I would say) to familiarize yourself with how bugs are reported in the project you’re participating with. In Ubuntu it’s the Bug Squad team - perhaps even join it. I view Bug Squad members as the little bee-workers that are front-line organizers and helpers in the fight against bugs.

Think about it. An hour or so is not that much to dedicate to learning and understanding how your contributions will (or not) affect Ubuntu. It will also give you tools and guidance to become helpful and efficient in any bug reporting. I am not saying everyone should join! But those of you who don’t join need to at least understand how a bug report is treated on the receiving end.

I’d like to contribute 10 things to avoid and 10 things you can do if you want to increase the chances of getting good results from bug reporting (meaning a fix or solution). Some of them come from the Best Bug Reporting Practices wiki page.

1. Look for existing bug reports that match your problem. It saves a tremendous amount of time when several people do this. It helps confirming a bug and tying loose ends Checking upstream and linking those is very nice too!
2. When filing a new bug, mention the ID’s of all bugs that sound similar. use “Bug #XXX”, this provides an automatic link. Someone can dupe them together later.
3. Add missing data (including video, YES VIDEO, screen captures, logs) to an existing bug. In some cases more is better.
4. Provide context. Consider what is unique about your system, and mention it. Is it brand new out of the assembly line ? Did it stay overnight outside at -40C ? Is your music collection that fails to import in Rhythmbox 40000 files big ? Did you just reinstall ?
5. Itemize the exact steps that result in the issue. Can you reproduce it at will? This is perhaps the single most important thing. If no one can reproduce your bug, chances are no one will be able to fix it. Providing clear steps dramatically helps.
6. Follow up on your bugs from time to time, even if they seem ignored. Kindly ask for a follow-up if/when appropriate.
7. Report if the issue goes away or remains when new Ubuntu’s come out.
8. Once you’ve reported a bug, or if you have a few that are important to you, give them visibility. Go to forums, mailing lists, or post them in your blog. Not everyone reads bug reports or knows an issue they have is being worked on.
9. Use IRC. Live chatting with developers on #ubuntu-bugs or #ubuntu-devel and asking a few questions while writing your bug report may help getting better information (like which package the bug should belong to).
10. Get confirmation (or rejection) as soon as possible. Befriend a developer, expose your bugs, use whatever means to have other people confirm or reject your bugs. Be proactive if you want your bug reports to get some “traction”.

Here are my don’ts:

1. Do not assume your bug report is more important because you’ve put several hours thouroughly detailing it. I know because I have done that. In many cases I see such reports as a documentation available to others, so they don’t repeat my own mistakes.
2. Don’t be rude. Whatever the frustration, it’s not helpful to the bug’s resolution. I personally find this is the hardest to do When in doubt, read again the Ubuntu Code of Conduct, take a few minutes before ranting.
3. Don’t cite external links with lenghty discussions - unless you summarize them in one or two sentence. - this multiplies exponentially the time required to assess a bug’s status, importance, etc.
4. Do not assume “they must already know about this” - no one does. Making assumptions only adds delays while clarifications are obtained.
5. Don’t add “me too” responses, unless you are giving more details that actually help confirming a bug in its early reporting. It wastes everyone’s time when reviewing a bug (not to mention emails generated).
6. Don’t post bugs with only a brief description of the problem. “XXXX doesn’t work” will get rejected or will expire. A model number for hardware by itself is not enough detail.
7. Don’t assume others will “just know” how the bug occurs. Sometimes non-technical details (like “the wireless connection always drop when I pickup my wireless phone”) provide important context.
8. Don’t fire and forget. Abandoned bugs rarely get fixed. If you are not willing / able to subscribe to your own bug reports and provide feedback, additional information, and even ultimately test possible solutions, make it clear in the bug report or don’t file it.
9. Don’t post bug reports in other languages than english. This may seem obvious but when you install Ubuntu for someone that will be using it in any other language than english, automatic bug reporting may kick in and give the false impression any reports can be filed in another language. Educate your non-English speaking Ubuntu “customers” about this.
10. Don’t assume every issue is critical. Between fixing a screensaver that crashes Ubuntu (easily worked around) or fixing a RAID issue that affects all server installs, what do you think should get more attention ? Importance is relative. Not everyone’s emergency is someone else’s too.
11. EXTRA: Don’t ignore guidelines and procedure. If you know a rule, don’t ask for exceptions!

Last but not least, if your bug concerns business needs and is stopping your business or your customer or any commercial activity, consider actually paying a developer or company to look into it. Part of Canonical’s support services includes bug escalation but there are many other ways to “financially speed up” a bug’s resolution. Citing business concerns in Launchpad to speed up a bug’s resolution is not what I mean here, but actually paying someone to go through the community process for you or your company / organization.

If anyone has other tips to contribute, I’d love to hear them. I am far from a bug reporting expert so I’d love to learn any new tricks and tips here

A few days ago a friend asked me “How come Dell PCs with Ubuntu are only 50$ less than Windows ?”. I was actually suprised by his question and I thought I would share my answer.

If I apply the closed, non-free business models around proprietary software, I really think Ubuntu PCs should be much more expensive (like U$1000 more) than any Windows comparable machine. After explaining all you would need to add to a Windows install in order to make it comparable to Gnu/Linux, we actually agreed… I was then wondering what would happen if a tiny portion of Ubuntu users would contribute a portion of the U$1000 saved towards local development and advocacy efforts. Well, “finders, keepers” also works for me.

Think about it, I am sure you can come with more than this short list but… since being an Ubuntu user at home and at work,

1. I don’t need antivirus, firewall, cleanup, anti-spyware or other such ” security” software. This may require a bit more explanation, but what can I say. I my personal experience, I really don’t need any of this.
2. As a result of #1, I don’t actually need to waste a dual-core’s machine power so I can be “running a virus scan and management agent in the background“. I’d rather put that to good video transcoding use
3. As a result of #1, current sub U$500 cheap Celeron based laptops run just fine with only 512MB of RAM - they’re not ” useless” as I was told at the store
4. I can choose and download a healthy few thousands applications (including many servers like web, voip, etc.) from one central package/repository management application. Like, say, Windows update but for all applications. Multi-lingual, and including security updates, unlike Windows Marketplace. I do happen to work in spanish and french too.
5. I can have my systems (and all included applications) available in several languages at once.
6. I don’t worry about manual security updates, except for software I have decided to manually download and install from other sites (a rarity, but happens)
7. I don’t reinstall! Well, my work consists of advocacy and consulting / coaching / providing tech support so my main laptop does get reinstalled often. Home PC hasn’t had a reinstall for 3 years though.
8. I can keep using the oldest, crapiest hardware I love, like that PCMCIA reader or the “Windows 98-only” webcam, along the newer one
9. When I come across a missing feature / problem / documentation omission or translation problem I take the opportunity to contribute back and learn in the process
10. I can copy all this to any amount of people around me, without restrictions or underground illegal activities - the only limit being my bandwidth, and ability to give out CDs or other media. In fact I am often asked if the software I used is legal, as I seem to have a little or big app for most any use.

So how much is that worth to you ? I was thinking I would need to talk about the freedom, the formats, the licences, patent problems, etc., I guess that’s for another afternoon when I chat again with my friend.

Nicolas nous rappelle que jeudi prochain (21 juin) il y a une présentation organisée par FACIL au CRIM. Damien Seguy va nous sortir de notre petit nid douillet en nous parlant de La Sécurité des applications en ligne.

J’ai rencontré Damien à plusieurs reprises et je dois dire que je regrette beaucoup de ne pas pouvoir aller à sa présentation, alors ne manquez pas de lui dire bonjour de ma part si vous y allez suite à votre lecture de ce billet

C’est pas les endroits intéressants qui manquent pour travailler à Montréal..! VDL2 Communications recrute, allez faire un tour si vous avez un fort profil “web”

Bon, c’est un peu dernière minute mais… à partir de demain et pour le weekend au complet, à ne pas manquer: RoCoCo 2007. Merci à Marc Laporte et Simon Law qui ont fait passer le mot :).

While attending the Ubuntu Developer Summit in Sevilla, there’s been quite a good amount of presentations and of course the usual problems with LCD projectors. In some cases we lack the time to access a venue and prepare in advance but most of the time we have no idea what we can do to “save the day”.

This week during the morning lightning talks, which are short presentations and demos shown before the actual spec meetings, a few people could not present due to the feared permanent “Searching for signal” message on the LCD. General reaction has been indifference, shrugging and, shockingly, just laughter. Although people directly involved with this take these issues very seriously, there is still that “RTFM” feeling around when things like this happen. I almost wish anyone laughing about this would be first line support for an important presentation and it happens to them.

Issues with external projectors will get a lot of love as part of the bulletproof-x, simple x-mode selection and other X specs being discussed and drafted for implementation in Ubuntu’s next version. Graphic drivers play an important role here, it will be interesting to see what ATI does knowing that its chipset can’t be supported in the current situation.

There is some extraordinary work coming from the community, but also many people involved from the business side of things. Intel and other important players in this area at UDS, not to mention developers working full time on this. It seems all the pieces needed to have something close to a complete solution are out there and will be put to good use in Gutsy Gibbon.

Meanwhile, here are some ideas to get your presentation going under Ubuntu. Be careful as you may become the “LCD projector specialist” or hero of the day

Obligatory pre-presentation work

Before making your presentation, rehearse your “steps before having my presentation display”. Cleanup your desktop. Change that wallpaper. Have your presentation one-click away from the desktop. Have a USB key handy with your presentation in both the original format and some other easy to show format like HTML or PDF. If it involves video, try using open formats like Ogg Theora, maybe even have cross-platform media viewers on the stick.

Another good idea is to ask around if there are any other people willing to help.

Generally speaking, I can’t stress enough why you should get all these details sorted out *before* trying to solve the actual PC-to-LCD problems you may encounter.

If you know about LCD projectors, external displays, BIOS options, xorg.conf and general presentation-scenario configurations, by all means register at the front-desk and have an announcement made about your availability to help.

Way #1: reboot while having your external display plugged in.

While not the most elegant, I’ve found this works 100% of the time if the resolution matches or is supported by the projector or external display I am using. Most modern projectors adapt to the signal sent from the feeding video source, although you may not have a local graphic display (on your LCD).

Way #2: Configure your external display and modify your config file to handle multiple layouts

My laptop really has bad suspend support (or should I say none) so I don’t mind booting into text mode for quick access to data. It also lets me choose what graphics setup to use depending on where I am. Here’s how I do that:

• Configure the internal graphics adapter as usual. Make a backup of the resulting xorg.conf file.
• Connect an external LCD, reboot. Configure it as usual (sudo dpkg-reconfigure xserver-xorg. Make sure it works. Backup the resulting xorg.conf file under another name.
• Combine both xorg.conf files by using ServerLayout sections. Here’ s my example xorg.conf. Reading the xorg.conf man page helps a lot in understading how this works.
• At boot time, you will be presented with a text login. Once logged in, start your graphic environment by using: startx -- -layout <ServerLayout section identifier>